THIS DOCUMENT IS SUBJECT TO LEGAL PROFESSIONAL PRIVILEGE AND MUST NOT BE DISCLOSED TO
ANY PERSON WITHOUT THE EXPRESS AUTHORITY OF POST OFFICE LTD GENERAL COUNSEL OR
CARTWRIGHT KING SOLICITORS
Horizon data
Lepton SPSO 191320
STATUS: DRAFT
Version: 1
Last edited by:
Last edit date: 12/06/2013
POL00196708
POLO00196708
Horizon data -
Executive Summary
A transaction took place at [MM on the
04/10/2012 at 10:42 for a British Telecom bill payment for
£76.09; this was paid for by a Lloyds TSB cash withdrawal for
£80.00 and change give for £3.91. At 10:37 on the same day
the British Telecom bill payment was reversed out to cash
settlement.
The branch was issued with a Transaction Correction for
£76.09, which they duly settled; however the postmaster denied
reversing this transaction and involved a Forensic Accountant
as he believed his reputation was in doubt.
Reviewing the data
On looking at the credence data, it clearly indicates that the
reversal was completed by [Ry IJ et 10:37
04/10/2012 and was reversal indicator 1 (existing reversal)
and settled to cash. An existing reversal is where the session
number/Automated Payment number has to be entered to reverse
the item. (Copy in Appendix 1)
The fujitsu logs were requested for this branch, but whilst
waiting for these to arrive communications took place with
MMM, «2: Fujitsu for more details to gain an
understanding what had occurred at this branch.
Questions asked and extracts from various emails in response.
Question - I am requesting fujitsu logs for [J to
look at a reversal that I) IMJ denies transacting, do
I need to request further details, and also could you explain
what happens when the system fails. (JBM looked at data at
his end prior to me receiving the fujitsu logs. (Copy in
Appendix 1).
Answer - This shows that Session 537803 was successfully saved
to the BRDB, but when the user Logged On again
Recovery reversed the session in session 537805.
It isn’t clear what failed, but if it was a comms error, then
the system would have printed a disconnected session receipt
and the Clerk should have given the customer £80 and told him
his Bill was unpaid. The fact that there is no indication of
such a receipt in the events table suggests the counter may
POL00196708
POLO00196708
have been rebooted and so perhaps may have crashed in which
case the clerk may not have been told exactly what to do.
The reversal was due to recovery (Counter Mode Id = 118) so
this was not an explicit reversal by the clerk. This scenario
is fairly rare so it is certainly quite easy for the clerk to
have made a mistake and either he or the customer could be in
pocket / out of pocket (depending on exactly what happened!).
The system is behaving as it should. (email 30/01/2013)
Question - I can clearly see the recovery reversal on the
fujitsu logs received, but would this have been clear had we
not previously discussed this issue. (Copy of transactions
and events in Appendix 1)
Answer - Note that the standard ARQ spreadsheet may not make
it easy to confirm that the Reversal was part of Recovery, but
the underlying logs used to extract them can show it. (Email
30/01/2013)
The files 4 to 25 Oct 12.xls and Events 4 to 25 Oct 12.xls are
part of the standard ARQ returned. Rows 141 to 143 of 4 to 25
Oct 12.xls clearly show a Reversal. Also Row 70 of Events 4
to 25 Oct 12.xls shows that session 537803 (ie rows 138 to 140
of 4 to 25 Oct 12.xls) has been recovered and this event has
the same timestamp as the Reversal Session. Also row 71 of
Events 4 to 25 Oct 12.xls shows that a receipt was generated
from the session 537805 (not explicitly, but it was the only
session at that time). This receipt would have told the user
that a Rollback had taken place (but the logs don’t make that
explicit). If that is sufficient for you purposes, then you do
have all you need in the standard ARQ.
However what I was able to confirm from my look at live data a
couple of weeks ago and is also held in the underlying raw
logs is confirmation that the reversal was generated by the
system (and not manually by the user). What might also be
available in the underlying logs is whether or not the system
was re-booted - I suspect it was but have no evidence one way
or the other (and it isn’t in what was extracted this time
either). I can confirm that the user did Log On again (row 69
of Events 4 to 25 Oct 12.xls). (Email 11/02/2013)
Question - I can see where this transaction is and now
understand the reason behind it. My main concern is that we
use the basic ARQ logs for evidence in court and if we don’t
know what extra reports to ask for then in some circumstances
we would not be giving a true picture.
I know you are aware of all the horizon integrity issues and I
want to ensure that the ARQ logs are used and understood fully
by our operational team who have to work with this data both
in interviews and in court.
Just one question from my part - if the reversal is system
created but shows as an existing reversal, could this not be
reflected with a different code, .i.e. SR (system reversed) to
clear up any initial challenges. My feelings at the moment
are not questioning what Horizon does as I fully believe that
it is working as it should, it is just that I don’t think that
POL00196708
POL00196708
some of the system based correction and adjustment
transactions are clear to us on either credence or ARQ logs.
Answer - I understand your concerns. It would be relatively
simple to add an extra column into the existing ARQ report
spreadsheet, that would make it clear whether the Reversal
Basket was generated by Recovery or not. I think this would
address your concern. I’m not sure what the formal process is
for changing the report layout. Penny can you advise as to the
process: Is this done through a CR? (email 13/02/2013)
Recommendations
I do believe that the system has behaved as it should and I do
not see this scenario occurring regularly and creating large
losses. However, my concerns are that we cannot clearly see
what has happened on the data available to us and this in
itself may be misinterpreted when giving evidence and using
the same data for prosecutions.
My recommendation is that a change request is submitted so
that all system created reversals are clearly identifiable on
both fujitsu and credence.
Security - Fraud Analyst
12 June 2013
POL00196708
POL00196708