FUJ00121499
FUJ00121499
POST OFFICE ACCOUNT
FAD
Review of Expert Witness Report : Claim CR101947
Report received 6" February from POL. Written by Jason Coyne from Best Practice
Group ple. Law Society 2003 Accredited Expert Witness No. 229.
Background
POL have been in dispute with PM of this Outlet since mid 2000. Essentially, POL
had made a claim against the PM for losses at the Outlet, against which she had.
counter-claimed that the problem was caused by the Horizon system and she was
refusing to release the equipment as she believed an examination of it would vindicate
her. A Court Order was made on 19" February 2003 that a computer expert examine
the equipment.
POA’s first involvement was a request made 8" August 2003 by POL that we provide
a Witness Statement “about the Horizon equipment and what it contains (or doesn’t)
and give Mrs W a chance to object”. POL wanted the Court to overturn the Court
Order so that POL could recover the equipment.
On 20" August a fax was received from POL explaining the situation and requesting a
Witness Statement to the effect that there was nothing on the equipment that would
assist the PM in her claim and that it should be returned.
The following day I replied, by email, stating that I was unwilling to produce a
Witness Statement at this stage but explaining what information existed on the
equipment, what would happen if it was switched on and that we would not allow 3
parties access. I also explained how we could help POL. I received no reply to this
email.
On 6" February POA received a copy of the Expert’s report with a request from POL
for an early response. POL are concerned that the Expert’s opinion (that the system
was at fault) might set a precedent against future POL prosecutions.
I understand that there is a Case Management Conference on 25/02/04.
Basis Of Response
Before addressing individual points from the Expert’s report there are two key areas
of understanding to be established; the first is the function and objectives of the
Horizon System Helpdesk (HSH), the second is the way that the Horizon system
handles transactions should a reboot be required part way through a customer session.
Horizon System Helpdesk
The HSH represents the 1* line of support to Post Masters. It operates under strict
Service Level Agreements covering aspects such as pick-up time, first time fix, and
time to close. These measures are imposed by Post Office Ltd and are designed to
ensure that PMs receive a quick response to their call and, to the extent possible over
the ‘phone, a timely return to normal business operations.
Depending on the nature of the call the HSH operator would work with the PM to
solve the problem and return the Outlet to normal operation as soon as possible, in
line with the prevailing SLAs. If this could not be achieved the call would be
escalated up the support channel to 2", 3 or 4" line depending on the severity of
problem. Again, the primary objective is to return the Outlet to normal operation as
soon as possible and rebooting the Counter often meets that objective. This does not
mean that the problem was closed at that point in time, as a detailed scrutiny of
overall problem management in Post Office Account would reveal.
Transaction Handling on Reboot
The primary interface between the Post Office Clerk and the external customer is the
Customer Session. Any transactions that are undertaken within a Session are stored on
a Session Stack pending a Settlement transaction whereby goods and services
provided by Post Office to the customer are paid for. Only after the Settlement has
been confirmed and a receipt printed will the totality of transactions on the stack be
transferred from the Session Stack to the TMS Journal and a record maintained of the
Stock Unit movements. Once the Stock Unit is ‘rolled over’ (balanced) the various
pending movements will be finalised and reflected in new Stock Unit balances.
It is at this point that any discrepancies and imbalances between Stock Units are
identified and handled through reconciliation and Post Master manual intervention. It
this context a discrepancy is in fact a balancing entry to ensure the Cash Accounts
receipts and payments tables agree. A discrepancy could occur, for example, if the
Post Master incorrectly declared his cash or stock to the system against which the
system compares its own record.
Ifa Session is interrupted pre-Settlement, perhaps through a fault that requires a
reboot, the Session — and consequently the Session Stack - is not maintained and has
to be re-started once the system has been returned to the Post Master. The only
exception to this is for Automated Payment (AP) transactions where a smart device
may have already been charged before the payment was made. In this instance the
system will, on reboot, prompt the Post Master to complete the AP transaction
through to Settlement. All other transactions that may have been on the Session Stack
will be lost.
Given that goods should not be transferred to the customer side of the Counter until
Settlement has taken place there should be no opportunity for stock to be removed.
without a corresponding cash input:
The Expert’s Opinion
Taking each opinion as it occurs in the report I would offer the following by means of
explanation, confirmation or refutation.
‘Reasonableness’ of calls to HSH
The Expert was unable to make direct comparisons between similar Outlets due to the
absence of records. While this was true of audit data formally available to POL, POA
are able to review an unregulated archive of records of the other installed 6 Counter
Outlets over a comparable period. The table below shows the output from that
analysis :
FAD
005323
PO Name
Headingly
Install
Date
06/10/99
x
FUJ00121499
FUJ00121499
%Non =»
A&G ___ Soft
73%
36%
005715
Dungannon
18/10/99
68%
40%
009116
Halstead
28/09/99
81%
44%
FUJ00121499
FUJ00121499
013613 I Haverfordwest I 04/11/99 I 48 I 7 8 2 I 22 3 85% I 46%
153405 I Cleveleys [1] I 09/02/00 I 101 I 15 6 5 1 I 35 14 I 16 85% I 35%
153405 I Cleveleys [2] I 09/02/00 I 85 I 15 6 5 1 I 35 14 82% I 41%
176323 I Amley 13/10/99 I 87 I 23 8 4 7 I 29 12 74% I 33%
185611 I Penarth os/0/99 I 58 I 15 5 1 3 I 15 14 74% I 26%
250704 I Yorkgate 2ai0g/99 I 32. I 5 4 3 I 16 3 84% I 50%
292323 I Otley 07/10/99 I 34 I 10 1 5 1 [44 2 71% I 32%
333427 I Darwen 21nosa I 55 I 13 8 2 5 I 13 3 76% I 24%
345432 I Wilmslow 25riois9 I 29 I 4 2 6 47 6 86% I 24%
431614 I ColwynBay I 05/11/99 I 89 II 19. 2 3 2 I 38 13 79% I 43%
Call Legend
Type
A Advice and Guidance
F Reference Data
H Hardware
\ Implementation
kK Cash Account
M Customer Complaint
N Network
° Operational
s Software
T Training
x Other
Y Rollout Helpdesk
Zz Security
[1] Cleveleys complete HSH call count including Rollout calls
[2] Cleveleys HSH call count without Rollout calls and the basis for comparison.
Analysis of the comparable Outlets shows that in terms of total calls made (3 from
highest out of 12), the %ge that were non Advice & Guidance (4"" from highest) and
the %ge that were Software based (5" from highest), Cleveleys numbers are broadly
comparable with the group of Outlets
To draw any firm conclusions as to ‘why?’ would require judgement over the
capabilities of the staff in the first place, the correct operation of the equipment,
effectiveness of the training programme and the extent to which the Cleveley’s staff
resorted to the HSH at the first opportunity.
Statement by Ms Elaine Tagg
A total of 101 HSH calls were raised between 09/02/00 (install date) and 20/11/00
(termination date) of which 15 are classified as Advice and Guidance and 16 are to do
with the Rollout itself. Based on the analysis, and without analysing each and every
non A&G and RO call record it would be hard to dispute the opinion of the Expert on
Ms Tagg’s statement.
Operator advice to ‘Reboot’
In this context the opinion of the Expert, that “this instruction treats the effect and not
the cause” is correct.
However, it would be incorrect to assume that no further work is carried out by POA
to address the various blue screen/system freeze/screen lock problems. Regular
maintenance updates are made to address these problems within the normal Release
programme.
Summary : Defective Equipment
The criticism that the technology installed at Cleveleys was ‘clearly defective’ is
subjective and based on the raising of 70 HSH calls over a 10 month period. There is
no attempt to substantiate the claim nor to draw any comparisons with external
benchmarks.
Summary : Closing Calls
As already stated the HSH is targeted at returning Outlets to normal working as fast as
possible and are not in a position to analyse system error messages displayed on
screens. This is governed by Service Level Agreements instigated and monitored by
Post Office Ltd. So while the Expert’s statement is fact it does not take into account
the objectives of the HSH or the manner in which it operates.
Summary : Worrying Discrepancies
It is difficult to comment on the statement made by the Expert in this part of the
Summary although he is alluding to the fact that system errors may be responsible for
this. I have explained why this cannot happen earlier in this report.
The argument has been put forward by a number of PMs in the past when challenged
and prosecuted by POL for alleged fraudulent behaviour and each time it has fallen
when confronted by transaction data that demonstrates that the system was operating
normally during the disputed time period. Post Office Account actively supports the
Post Office in investigating potential frauds and have supplied historical transaction
data to POL Security Investigations in support of their investigations and
prosecutions. Our understanding is that a claim of ‘the system is responsible for the
discrepancies’ is usually the first line of defence by PMs under investigation. Again,
to our knowledge, the data we have supplied to POL SI has never been successfully
challenged, in court or out of it. From this we infer that the system has always
operated correctly, including the period under question at Cleveleys.
Issues Around the Confiscated Equipment
We understand that the PM at Cleveleys has confiscated the Horizon equipment as
she believes that its contents will vindicate her claim that the system was at fault. On
21* August 2003 I wrote to Jim Cruise and explained the following :
1. Transactions exist on the Counter for no more than 34 days after which they are automatically
deleted by a Riposte routine (Riposte is the messaging software that passes information around the
whole system and generates the transaction information). In the case of this particular system
transactions MAY still exist, provided that the counter has not been powered up at any time since
the last "active day".
2. If a Counter has been switched off for more than 35 consecutive days and then switched on
Riposte will not start-up. This is a security device to deter a Counter being stolen and subsequently
being attached back onto the network in order to conduct transactions illegally
3. If Riposte were made to work after 35 days it would immediately check for transactions >34 days
old and delete them.
4. Under no circumstances would we allow a 3rd party direct access to a counter. The filestore is
encrypted and for a 3rd party to make sense of the data we would have to release to them details of
the encryption key. This we would not do.
FUJ00121499
FUJ00121499
We also offered to assist in the case :
1. If this is to be pursued then the work would have to be undertaken by our technical specialists in
Bracknell, possibly with the 3rd party in attendance as an observer. Said 3rd party would require
to be security cleared before being allowed access ?
2. We could make no guarantees about recovering any data since there are a number of activities
that we have had no cause to attempt before and therefore could not be certain of the outcome.
From the Celeverleys’ PM’s perspective the chances of her obtaining anything of use,
even if it is recoverable, is remote. Unless the discrepancies occurred within 34 days
of 20" November (when I believe the equipment was switched off), and assuming that
information can be recovered, the transactions will show that the system was
operating correctly.
Audit Data Recovery
Our note on 21*' August 2003 also identified why we could not provide any
contemporary transaction logs from the audit archive at that time :
1. We will have no record of any transaction data from Cleverleys dated before November 2000 in
the central audit archive since this is automatically deleted 18 months from the date that it is written.
So, if 30th November 2000 was the last active day for the Counter that data would have been
deleted on or about 30th May 2002.
2. Similarly, there will be no Help Desk logs since these are also deleted after 18 months.
Conclusion
The report presented by the Expert is based on an analysis of HSH records and not a
detailed understanding of how the Horizon system works, or even the prime
objectives of the Horizon System Helpdesk. Consequently the opinions expressed in
the report, while not always incorrect, do not present the whole story and are
presented from a single perspective.
We have identified where we could not argue against an opinion or where the opinion
is correct as a statement of fact but lacking in context. We have also identified where
we disagree with the opinion expressed.
We have confirmed what information might or might not exist on the equipment
being withheld by Mrs Wolstenholme and what we, Fujitsu Service Post Office
Account, might be able to do to recover transaction information held on the
equipment. We have identified the risks and constraints around that work.
FUJ00121499
FUJ00121499