POL00002239
POL00002239
Alwen
H Simon Baker
Sent: Mon 1 7 2013 6:04:12 AM
Subject: Re: FW: Spot Review 001
Ron
A couple points.
1. The ability for Horizon to switch to a mobile single if the land line is broken is not “crack pot". In retail organisations this as best
practice but often not implemented because of cost.
2. Mr Armstrong is correct, the three receipts all print at once when the sub postmaster pressed cancel. The is the only point in the
process a disconnection receipt is required.
3. I understand Mr Armstrong's point about handing the bill back to the customer, all I can say to that is that when I am working at
the counter I haven't done it (and I have had some very impatient customers}.
Regards, Simon
From: Ron Warmington [mailto:ron.warmington;
Sent: Sunday, June 30, 2013 10:13 PM
To: Simon Baker
Cc: 'Tan Henderson’ <irh
Simon: FYI. John is right about the receipts all printing out at the same time (10:36hrs BST). T also
don't think that John can, in all fairness, be faulted for stamping that BT bill as paid. This is all about
real life at the counter ina pretty difficult situation. The customer can walk away whenever he wants
to... and did just that in this incident. Let's face it, backing up a complex, inter-active, real-time,
system with a mobile phone line is a pretty crackpot design, seems to me. Fujitsu and POL have designed
a complex Recovery processing process that might be OK if it were only triggered a few times a year in
each branch. That wasn't the story here.
Regards, Ron
From: John Armstrong [mailto:jc_armstrong,
Sent: Friday, June 28, 2013 4:20 PM ~
To: Ron Warmington
Subject: Re: FW: Spot Review 001
Hi Ron,
Did you get the ipad photos of the disconnection and recovery receipts last night?
Have just read your latest email.
In Gareths(?) report he is assuming that the discconnection receipts printed out after each attempt by the system to settle
the basket. As each individual receipt shows the same time of 10:36 that indicatesthat the system churned out all 3 receipts
at the same time. One minute later (10:37) a recovery receipt was printed out. This must have also been produced
automatically as I would NOT press cancel midway through a transaction.
The comment that I should not have stamped the telephone bill I will treat with the contempt it deserves. If I had not
stamped that bill I could certainly have been accused of fraud at a later date. It's called guarding your back!!
As regards keeping the customer in the premises, please get him to explain to me just how I go about that as nobody knew
how long the transaction was going to take.
regards F/1095.1/4
POL00002239
POL00002239
John
--- On Fri, 28/6/13, Ron Warmington <ron.warmingto I
From: Ron Warmington <ron.warmington’_
Subject: FW: Spot Review 001 .
To: "Armstrong John" <jc_armstron;
Cc: "Alan Bates" <alan.bate:
Date: Friday, 28 June, 2013, 13:33
wrote:
, "Ian Henderson" <irht
Chaps/Kay: FYI. Ron.
From: Ron Warmington [mailto:ron.warmingtoi
Sent: Friday, June 28, 2013 1:27 PM
To: 'Simon Baker’; 'lan Henderson’
Ce: "Lesley J Sewell’; ‘Alwen Lyons!
Subject: RE: Spot Review 001
Yes... Thanks but all that was perfectly clear in the very thorough earlier
response. The customer left the counter (happy no doubt with his stamped
(as paid) telephone bill) between 09:32 GMT (10:32 BST) and 10:36 BST. And
yes, I know that John should not have given the customer the stamped.
telephone bill, or allowed him to leave the counter, before 10:36 but the
truth is... the customer HAD already left.
Regards, Ron.
From: Simon Baker [mailto:simon baker!
Sent: Thursday, June 27, 2013 9:15 PM
To: Ron Warmington; ‘lan Henderson'
Ce: Lesley J Sewell; Alwen Lyons
Subject: RE: Spot Review 001
Ron
T asked Gareth to produce a time line of the event using the XML - shown
below. Looking at this it shows that the receipts printed straight away -
no time lag.
F/1095.1/2
Regards, Simon
Gareth's comments below:
Note all times are in GMT, but as this was early October the Branch was
operating in BST so all times should really be 10 am rather than 9am.
However I'm keeping to what the logs say and they record in GMT at all
times.
1. The Bill Payment was recorded at 09:32:52
2. The Banking Withdrawal (to pay for it) was recorded at starting at
09:33:01 and completing at 09:33:28. This would have included the time
taken to contact the Bank and print the Banking Receipt. The actual request
to the Bank for withdrawing the funds was sent at 09:33:16. A confirmation
of receipt of the authorisation was sent to the Data Centre at 09:33.28.
3. The change of 73.91 was recorded at 09:33:33
4. The first attempt to record the Basket occurred at 09:33:34.
5. The second attempt (first automated retry) occurred at 09:34:19
6. Therefore the message asking if a Retry or Cancel was required
would have been shown at about 09:34:40 (this is not audited). Retry must
have been selected at this point
7. A third attempt at sending the Basket occurred at 09:35:08
8. _ A fourth attempt (automated retry) occurred at 09:35:53
9. Therefore a message asking for a retry or Cancel would have been
shown at about 09:36:25. At this point Cancel must have been selected thus
producing the Disconnected session receipt. This fits in with the time of
10:36 in the email below
From: Ron Warmington [mailto:ron.warmingtoné
Sent: 26 June 2013 10:13
To: ‘lan Henderson’; Simon Baker
Ce: 'Armstrong John’
Subject: FW: Spot Review 001
POL00002239
POL00002239
F/1095.1/3
Input from John Armstrong ... I'd always suspected that the customer had
left the building by the time the system started to tell John what he needed
to do (with the now absent customer).
John: Well done and many thanks. Ron.
From: John Armstrong [mailto:jc_armstrong:
Sent: Tuesday, June 25, 2013 11:34 PM
To: Ron Warmington
Subject: Re: Spot Review 001
Hi Ron
Having read your report I searched through the weekly records for the 4th
October 2012 and found THREE Disconnected session receipts all with the same
session ID of 1-537803 showing :-
British Telecom
0 @76.09 0.00
LTSB cash wdrl
1- @ 80.00 80.00-
Total due to customer 80.00
Cash from customer 0.00
Cash to customer 80.00
Balance 0.00
The time shown on these slips is 10.36 yet I had had the foresight to enter
the time of 10.32 am on the customers bill alongside the amount paid of
276.09. This means that the customer had already left the office by the time
these receipts were printed out by the system.
POL00002239
POL00002239
F/1095.1/4
A 4th receipt with a session ID of 1-537805 timed at 10.37 shows :-
Recovery successful
System correction
British Telecom
1- @ 76.09 76.09
Total due to customer 76.09
Cash from customer 3.91
Cash to customer 80.00
Balance
0.00
As the customer would testify he did not give me ?3.91 back nor did I repay
him ?80.00 but assumed that all transactions had been completed as the
system did not issue receipts until 4 minutes had elapsed from me issuing
the receipted and timed telephone bill., by which time the customer had
already left the office. As I know that it is impossible to reverse a bank
card withdrawal why would I be aware that I should be looking for a reversal
on a transaction log later in the day?
Why did the Horizon system, print out 3 disconnected session receipts for
the same transaction all with same session ID's and for the same time? This
was unprecedented and certainly no clear instruction given on screen as to
how I should proceed other than to trust that Horizon had worked properly
which clearly it had not.
My issue was and remains that the transaction log infers that I had
knowingly reversed all 3 parts of the transaction and pocketed the proceeds,
a fact referred to in the reply received from Mr Winn with a demand that
this money be repaid to POL.
Ron I apologise for not thinking to search the records earlier for
disconnected session receipts but genuinly felt that all transacton records
POL00002239
POL00002239
F/1095.1/5
had been on screen and therefore unavailable.
Regards John
--- On Tue, 25/6/13
<ron.warmington
From: Ron Warmington <ron.warmington:
Subject: Spot Review 001 .
To: "Armstrong John" <je_armstrong.
Cc: "Ian Henderson"
<alan.bates:_
Date: Tuesday, 25 June, 2013,
>, "Alan Bates"
John: As I mentioned, we are including your incident in our Interim Report
to be delivered to MPs on July 8th. It is one of only four Spot Reviews
that we are, at this stage, disclosing.
Here is what we have in the Report on your incident. If you see anything at
all here that needs to be corrected, or could be improved in any way, please
let me know and I'll change it. Frankly, what I would have expected in a
matter like this is that someone from POL would have called you to make sure
that you were perfectly clear on what had and had not been processed... and
what you (and POL) needed to do to sort it all out. I remain unconvinced
that flashing up screen messages and printing out "Receipts" is adequate as
a Standard Operating Procedure.
Jan and J are particularly interested to know whether you received the
printed Disconnect and Recovery "Receipts" that POL refers to in its
response (examples were included in that "Story Board", as POL called it,
that I recently sent you (see "POL has also not (yet) satisfied Second Sight
that the SPMR really was presented with the screen and printed-out messages
that are meant to be produced" near the end of the report extract).
REPORT EXTRACT FOLLOWS HERE...
Spot Reviews:
SR 001:
The SPMR reports that there were intermittent internet connectivity problems
(also reported to Chesterfield) on 4 October 2012. Online payments and
POL00002239
POL00002239
F/1095.1/6
POL00002239
POL00002239
withdrawal transactions were sometimes successful but also failed on
occasions. It is possible that Horizon was partially operating through its
back-up (mobile phone) connection. Some card payments had to be attempted
two or three times before being accepted. At approximately 10:32 a customer
tried to pay his 776.09 BT phone bill with his LTSB card but was not
successful. The customer then withdrew ?80.00 cash and used this to pay the
phone bill. The SPMR stamped the customer's phone bill to evidence receipt
of the cash, returning change of 73.91. Several weeks later, the customer
retumed from holiday to find his phone had been cut off due to non-payment.
The SPMR's examination of the Transaction Log showed that all components of
the transaction had been reversed. The SPMR did not initiate those reversals
nor did he receive any reversal notifications. The SPMR raised this as an
issue with Chesterfield but was told that due to cost issues Horizon
transaction data could not be requested. It was implied that the SPMR had
stolen the money and he was told to make good the shortage. This meant that
2 people had paid the phone bill (the customer, who handed cash to the
SPMR... and the SPMR on instructions from Chesterfield). The SPMR was
informed that he should have a surplus of ?76.09 due to the reversal of the
transactions. The SPMR disputes this conclusion, but the more important
issue here is the automated, unreported, reversal of the transactions.
SR 001 - Summary of POL's Response:
POL's 10-page response asserts that the Spot Review:
2? does not demonstrate any failing in Horizon
2? principally asks whether a SPMR will be properly notified about
automatic reversals of transactions when Horizon is unable to connect to the
Data Centre
Second Sight remarked to POL about its use of the future tense in the phrase
"will be properly notified", pointing out that the investigators were not
interested in what POL's Operational Manuals and Core Software intended
should (or was meant to) happen but in what had actually happened in this
event. POL continued: "the analysis below shows that Horizon does provide
adequate notification". Note here the phrase "does provide", rather than
"provided". Again, POL's answer to the Spot Review revolves around what is
meant to happen, rather than proving what actually happened at the branch
counter.
POL further asserts, in its response, that the root cause of the
difficulties suffered by the SPMR was his failure to follow the on-screen
and printed instructions given by Horizon. POL claimed to be confident that
the SPMR knew that some transactions had been automatically reversed
because:
2? the branch had been suffering connectivity issues in the run up to
the incident in question (POL concedes that, on the day in question, "there
were, for example, 13 online requests for either Banking or Credit/Debit
Card Payments that appear to have timed out" and that "it is possible that
Horizon was partially operating through its back-up (mobile phone)
connection"); F/1095.1/7
2? when the transactions in question first failed to be processed
(because Horizon could not get a response from the Data Centre), Horizon
asked the SPMR whether he wished to cancel or retry the transactions in
response to which the SPMR opted to retry the transactions;
2? when the transactions failed again, the SPMR opted to cancel the
transactions;
2? Horizon then automatically disconnected and printed a "disconnect"
receipt that showed the transactions that had been automatically reversed;
2? astandard customer receipt was not produced and POL asserts that
this should have told the SPMR that the full transaction had not proceeded;
2 following the disconnect, the SPMR was required to log back on to
Horizon and duly did so;
2? following the log on, and as part of the standard recovery process,
Horizon printed a "recovery" receipt which again showed the transactions
that had been reversed and those that had been recovered.
Note: POL included sample "disconnect" and "recovery" receipts with
its response to this Spot Review but was unable to provide a copy of the
actual receipts that the SPMR was meant to have seen.
2? POL's response (and its attachments) also concedes the following (all
quotations from POL's response or attachments to that response):
2? there were 4 attempts (at roughly 45 second intervals) to store the
completed basket to the Data Centre. The first 2 use a connection type of 2G
and the other 2 use a 3G comms connection. From the branch's records, they
are all marked as having failed... but from the Data Centre's perspective,
one of the attempts did result in all the data in that basket being
successfully saved in the Data Centre but, due to the connectivity issues,
the branch did not receive a confirmation from the Data Centre. The branch
will therefore record this as a failure... and...
2? following a failure of the third attempt, the system would
automatically carry out a retry and attempt to save the basket to the Data
Centre yet again... and..
2? the cash withdrawal transaction for ?80 could not be cancelled.
Prior to the disconnect, Horizon had already contacted the customer's bank
to confirm that a cash withdrawal could be made from the customer's account.
The customer's bank had therefore already registered the withdrawal from the
customer's account and this transaction could not be cancelled.
Note: The above (which is a short extract from POL's very long
response) may seem quite complex. It IS quite complex, though it
doubtless mostly works perfectly well. What is NOT clear from POL's
response is that the impact of Horizon's Recovery Processing in this
instance meant that, while the customer's BT telephone bill was NOT paid,
the debit to the customer's bank account WAS processed. Second
Sight is more sympathetic than POL seems to be to the SPMR's difficulties
when all this happened. POL has also not (yet) satisfied Second
POL00002239
POL00002239
F/1095.1/8
Sight that the SPMR really was presented with the screen and printed-out
messages that are meant to be produced.
Second Sight has concluded that this event should be classified as "Type 3"
(the shortfall or surplus was caused by errors made by the SPMR or his/her
assistants/staff where POL/Horizon Processes may have been insufficiently
robust/error-repellent or error detecting or where POL has failed to provide
the SPMR with adequate information and/or support to mitigate the loss).
END OF REPORT EXTRACT.
Thanks again, John, for your help... and very best regards,
Ron Warmington, CFE, FCA
Director
2nd Sight Support Services Ltd
Website: <http://www.secondsightsupport.co.uk/>
www.secondsightsupport.co.uk
POL00002239
POL00002239
F/1095.1/9
RR RR A CORR RRR RRR RR GR RR CR GR GRR RR A RR CO GR ao
This email and any attachments are confidential and intended for the
addressee only. If you are not the named recipient, you must not use,
disclose, reproduce, copy or distribute the contents of this communication.
If you have received this in error, please contact the sender by reply email
and then delete this email from your system. Any views or opinions expressed
within this email are solely those of the sender, unless otherwise
specifically stated.
POST OFFICE LIMITED is registered in England and Wales no 2154540.
Registered Office: 148 OLD STREET, LONDON ECIV 9HQ.
2H 2 fF 2 2 2 2 FR 0 RF fF 0 2 2 oR fo of a oR a a
POL00002239
POL00002239
F/1095.1/10