POL00022598
POL00022598
Confidential and legally privileged
Horizon data
Lepton SPSO 191320
STATUS: DRAFT
Author: Helen Rose
Version: 1
Last edited by: Helen Rose
Last edit date: 12/06/2013
POL00022598
POL00022598
Confidential and legally privileged
Horizon data - Lepton SPSO 191320
Executive Summary
A transaction took place at Lepton SPSO 191320 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 JAROO1 (postmaster) at 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 Gareth Jenkins at
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 Lepton 191320 to look at a
reversal that the postmaster denies transacting, do I need to request
further details, and also could you explain what happens when the
system fails. (Gareth looked at data at his end prior to me receiving
the fujitsu logs. (Copy in Appendix 1).
t Session
user JAROOL
53786
was
On agai
at failed, but if it
Aim
uch a
= reboot: and
ha i z not have b
what to do.
told exactl
Helen Rose 2
POL00022598
POL00022598
Confidential and legally privileged
The reversal was due to recovery (Counter Mode Id = so this was
not an explicit sal by e clerk. This scenario is fairly rare so
it is certainly quite easy for the clerk to have m ke and
either he or the customer could be in pocket / out of pocket
ng on exactly what happened!). The is behaving as it
{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)
Note that the standard ARQ
t the Reversal » part
logs used to extract them can show it. (Email 30/
prea et may not make it
of Recovery, but the und
1/2013)
The files 4 to 25 Oct 12.xls and Events 4
tandard ARQ returned. Rows 141
show a Reversal. Also Row 70 of
shows that session 537803 (ie rows 138 to 14¢
s been recovered and this event has the same timestamp as
Reversal Session. Also row 71 of Events ¢ to 25 Oct 12.xls shows that
a receipt was generated from the s n 537805 (not explicitly, but
it was the only session at that time). This receipt would have told
the i nat a Rollback had taken place {but the logs don’t make that
> £ that sufficient for you pur then you do have
u need in the standard ARQ.
of
from n
in the
generat
also be
raw log i
tem (and not
underlying
t but
was
the user did Log on
11/02/2013)
that the
fe user)
r the
one way
e eit
again (row 69 of
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 some of the system based correction and
adjustment transactions are clear to us on either credence or ARQ
logs.
Helen Rose 3
POL00022598
POL00022598
Confidential and legally privileged
Answer - I understa
It woulc
report
add an extra column the existing ARQ
would make it clea ner the Reversal Basket
Recovery or not. I think this would address yo I’m not
formal ng layout.
; : enny
s done through a CR?
mail
3/02/2613)
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.
Helen Rose
Security - Fraud Analyst
12 June 2013
Helen Rose 4
POL00022598
POL00022598
Confidential and legally privileged
Appendix 1
Credence data and fujitsu transaction logs for Lepton SPSO
191320
Lepton credence data - downloaded from our credence data
Lepton fujitsu data - data supplied by Gareth prior to receiving the
fujitsu logs
Lepton 4 to 25 Oct 12 and Lepton Events 4 to 25 Oct 2012 — fujitsu
logs received
Lepton credence —_Lepton fujitsu data Lepton 4 to 25 Oct Lepton Events 4 to
data for 04-10-12.xIs for 04-10-12 G).xisx 12.xIs 25 Oct 12.xIs
Other information
0 normal transaction
1 existing reversal (AP transactions)
2 new reversal
Entry Method Title
Barcoded Transactions
Manual
Magnetic Swipe
Chip and Pin or Smart Card
wNnro
Helen Rose 5
POL00022598
POL00022598
Confidential and legally privileged
Chip and Pin used in
fallback mode (when chip
doesn't work and it is
then used as a Magnetic
4 Swipe
5 Scales (connected )
Helen Rose 6