POL00071427
POL00071427
Personal attendance
Client: Royal Mail Group PLC Sub Postmaster Litigation
Matter: Lee Castleton Matter no: 348035.135
Attending:
Name: Adrian Bratt Location: Date: 6 June 2006
Start time: Units:
Meeting taking place Fujitsu HQ in Bracknell.
In attendance were:
Stephen Dilley (SJD), Adrian Bratt (ARB) of Bond Pearce
Mared Hughes (MH) of Hugh James
Brian Pinder (BP), Peter Sewell (PS) Andy Dunce (AD) Ann Chambers (AC) Naomi Ellis (NE) Gareth
Jenkins GJ) -distinguished engineer of Fujitsu
Graham Ward (GW) of Post Office Limited (POL)
(1) The Horizon Disputes
The meeting opened with SJD introducing the agenda and outlining the Castleton case. SJD
outlining POL’s point of view with regards to settlement and that they are keen not to set a
precedent and they would like to take a firm line, thus giving a clear signal, such that the
accounting system is okay and they do not want to be taken for a ride. SJD thinks that we
will struggle to settle this case.
MH outlining Bajaj and Bilkhu disputes. MH noted that Tolhurst Fisher, the solicitors acting
for Bilkhu are positively advertising for claims from sub-postmasters with respect to the
Horizon system.
SJD noted all claimants are talking to each other and mentioned the bloggers website.
2) How Horizon Works
BP outlining that they can pull off all information and all calls to the helpdesk are logged —
this is vital and you can tell if the call is a technical, a user or a hardware issue. BP can
produce technical people to explain how the system works. Essentially the computer records
every key pressed.
SJD requesting a summary of how Horizon works. GW stated that Michael Gallagher and
Tony Uttins can provide a general statement of how Horizon works if that is necessary.
SJD - essentially is it a co-ordinated system like an automated till system.
Note: A customer session is effectively everything in the basket, ie everything in the
particular transaction. (stack). There is no chance of recording a partial session, you
either get all of the session or none of it.
<1.
1A.1173514_2
POL00071427
POL00071427
BP saying essentially it records every transaction and key pressed. Every “till” is connected
to servers at Wigan and Bootle (mirror data centres). They talk to each other and ensure
that they both have the same detail. Effectively there is a primary and a backup although no
one site in particular is designated a primary they both just copy each other. The
information goes to one server and the other, whichever it is, takes this information as it
happens.
GW said there is a touch screen set up and the price is already in the system which clears
down after the transaction stack is cleared. There is one stack per customer.
The system will give error notices and these are generated by Chesterfield depending on the
error, although Chesterfield would need to tell him about the details of this. With regards to
Castlefield there were no error notices generated.
Note: Helplines are :
The HSH helpline - this is for technical difficulties and is run by Fujitsu
The NBSC helpline - this is for procedural business issues and is run by POL
AD stated that he had produced a statement which was a brief overview of calls received to
the HSH helpdesk and how they were responded to. AD doesn’t know about the technical
aspects of this.
MH questioned what happens if it is apparent that it is of a more technical issue. AD said the
person taking the call will diagnose the problem and refer. Some calls are automatically
generated and logged. Usually this is out of hours.
BP stated that if work is done on the system overnight, critical events can occur on the
systems - which is the type of thing that would generate an automatic call.
(3) Castleton’s Part 20 Reply
1.1(i) with the non-communication between the PCs.
G) said every transaction is committed to the local PC and written to that hard disk. It is
also copied to the other PC in the branch, directly to the disk. If the communications are
working this happens immediately- if they are not communicating the PCs will catch up later.
The reporting is all done from the data on the PC you are working on.
If two PCs were not talking to each other this is irrelevant as to what goes to the central
system. At approximately 6pm the centre runs a process of checking the two PCs are talking
to each other and then communicates the data through. A report is produced if the two PCs
can’t talk and whether the information is sent through to the centre or not. Only the
gateway node (ie one PC terminal)will connect the centre. Each PC will detail all transactions
on both PCs though.
Note: How often is Castleton’s PC feeding through to the centre. On a normal day of 8.30-
5.00 the PC will collect through periodically as required. The transaction logs can be
analysed. For example if a banking withdrawal occurred this would be noted, for
example at a particular time and we would be able to tell that the communication
had occurred at that time.
A balance snapshot is based on information on the local PC. A full balance on the local PC
will tell you communications are not working and this will be recorded on the system. You
cannot check through audits when communications were not working but you can through
the full balance.
The PCs are designed to work stand alone and independently.
Note: A customer session is effectively everything in the basket, ie everything in the
particular transaction. (stack). There is no chance of recording a partial session, you
either get all of the session or none of it.
Balance snapshots will not be accurate if printed when the PCs are not communicating with
each other at that time. However if there is a disruption to the communications the PCs will
catch up the next time the link is restored. With regards to January to March 04, we can
check the central comms configuration at that point by looking at the audit logs and when
2
1A.1173514_2
POL00071427
POL00071427
the flushes occurred through to the centre. Although this is actually irrelevant as all reports
are done on branch PCs, data going to the centre is to go to POL’s central account.
1.1(ii) screen freezing.
GJ said that if the screen freezes, the effect on the balance depends on what we are doing at
the time. We would either get all of the session recorded or nothing. Once the PC comes
back online where the transaction was a debit card etc it will tell you at what stage the
transaction was at. However it does take approximately 15 minutes for the computer to
come back online. The system will reflect either for example 20 stamps down and the
money should be in the till or the 20 stamps are still there. It is therefore clear to the
subpostmaster whether or not they need to re-enter that data for the transaction that was in
progress when the PC crashed. The system will always reconcile itself.
For each session:
(a) The number of transactions are all recorded;
(b) Settlement occurs, ie cash is transferred one way or another, in or
out of the till;
(c) How settlement is paid is recorded.
At the end of the session it is all communicated or none is communicated. If the system
crashes none is recorded except for perhaps online transactions. The system will give
specific prompts asking what happened and you can tell what happened in the recovery by
going through the audit trails (this is difficult to do but it can be done).
(iii) blank screen
GJ not sure what they are really talking about it. It’s a user issue and doesn’t affect the
logging process. It should be irrelevant as the subpostmaster cannot be processing a
transaction if the screen is blank.
(iv) card swipe
If it doesn’t read after 3 goes then the number is keyed in manually by the PO user.. This
could be done back in 2004. It is obvious when the card doesn’t get read. Credit cards were
not supported at the time in question and they could not be inputted manually. There are
also standard instructions telling postmasters (PM) that they will need to clean the machine
on regular occasions. The reply says the system was failing daily. Calls should have been
made regarding this issue although none are logged. He should also know what cards are
supported or not. Difficu;t to see how this could have caused the losses.
Note: Check to see if there is a standard POL memo surrounding this issue.
(v) ONCH (overnight cash holding)
Each day must have a cash declaration identification. The user is asked to enter a
declaration identification number and they usually enter the same number every day and the
same number is used throughout the branch regardless of the terminal being used. If the
branch use separate identification numbers for different PCs the system will add the figures
together, although this does not affect the balance.
Small branches use one stock unit and two counter positions. If there are separate piles of
cash these can be declared separately and the system will add them together. This is the
purpose of the declaration identification.
When you balance you balance the whole stock unit, regardless of which counter it is at, this
occurs once a week and is separate to the ONCH.
The system will highlight discrepancies. With respect to the ONCH if PM types no. 1 or 2 and
declares more money out this will not cause a problem and won't affect the balance which is
declared separately although the ONCH is part of the mechanism for ordering extra cash - as
the systems predicts how much cash the branch needs from this figure. If you type 1 on one
machine and 2 on another the system will add these together and the PM will convince
himself that he needs extra cash. The system will think he has more cash then he has. The
only real effect at weekends is that the ONCH has funny figures on it. Usually the system is
3
1A.1173514_2
POL00071427
POL00071427
such that the centre plans out to send a certain amount of cash and the PM will phone the
call centre if there is not enough there. Declared cash is similar to ONCH and is done at the
weekend with balance and is compulsory. The declared cash and the ONCH should be the
same at the end of the week. The PM can print out a summary of the week’s ONCH’s for his
purposes. The ONCH should be carried out last thing on a daily basis. If it doesn’t occur the
system will prompt the PM for this the next morning. The report will actually detail how
many individual notes etc are in the till.
(vi) lost transactions
We can only say what was entered and not what wasn’t entered. If it is a cheque this will be
picked up again at some point. If it’s a cheque the settlement stage is recorded as a
cheque. The system keeps a running total of cash on hand and cheques on hand. The PM
can print off a cheque report which can be corroborated to physical cheques (ie double entry
accounting principles). The PM has responsibility to print off the report and corroborate that
the physical cheques are there. The print off report for cheques is called the cheque listing.
An adjustment from cash to cheque can be carried out if it has been entered incorrectly. You
cannot submit a cheque if it is not on the cheque listing as it will be returned by the clearing
system. If this cheque is submitted as cash this will be picked up. The process occurs at
4pm daily. This needs to be done as part of the balancing process and at this point the held
cheques should be at zero.
1.2(i) There would also be less benefit vouchers and so on. If you actually paid out £70
there would be a matching benefit foil. If he had handed out money and not taken a foil
then that is his problem but if he had taken a foil he could record it late (ie double entry
accounting principles)
1.2 (ii) date held locally only a problem with data on the other machine they are not
communicating. He should not send the cheque off but even if it does it will be picked up
later on. This is because all cheques are attributable to a particular post office and details of
the transaction should be written on the back of the cheques.
Reply 2.1 (page 6) - balance snap shots.
JG - A balance snapshot is a real time belief picture but obviously cannot physically count
the actual cash in the drawer and the information stays on the hard drive for 35 days.
Balance snapshots are based on what is actually on the local machine and the system will
give warnings if the machines are not communicating.
Lines 9 to 11 are not true.
2.3 The line stating that the balance snapshot should show the actual transfer of cash and
the cash countered in the suspense account to the extent that it will show the transactional
aspect of the transfer and how it affects the rest of the balance snapshot is true.
The money in the suspense account will stay there until it is sorted. Lee Castleton stating
that £4,000 from the cash account is transferred across to the suspense account and the
cash account should return to zero. Castleton is saying that via the balance snapshot he can
prove that is not happening. JG stating that is not true and he can show it is not true.
Referring to the letter on 18 January. At the top of the balance sheet you get a summary of
the shortage/surplus - this does not get recalculated. The balance document on Wednesday
which shows on a balance snapshot. Not balanced it will remain and the balance reporting
will cancel out any discrepancy. The balance snapshot will not show the transfer until after
the subpostmaster does a trial balance.
(4) Call Logs
AC - noted that she is third line support and only one of Lee Castleton’s calls came through
to her.
SJD3 referring to the e-mail between Richard and Julie. This was sent sometime after the
call received by AC and effectively cuts and pastes part of an e-mail from AC to Julie.
CALL LOG NO. 312090261 - 09.12.03 - This is referring to the PMMC Card. This is used by
PMs to log on to the system.
CALL LOG NO 401200574 - 20.01.04- This is referring to the ASDL update from ISDN. This
was a scheduled visit and was for the broad band update.
4
1A.1173514_2
CALL LOG NO 4012800325 -28.01.04 - Referring to discrepancies 3 weeks in a row on 28
January.
Note: Need to check when Post Office went live with broadband and when the BT engineer
went in. AC noted that she would have looked at this call when doing her
investigation.
CALL LOG NO 401290358 - 29.01.04 - REM. These are REMittances accepting new stock
etc. Have REM‘d out when a cheque or cash leaves the system. This call is bounced to
NBSC.
CALL LOG NO 402020111- -02.02.04 — At approximately 3.30 am the PC’s do a refresh and
occasionally you get glitches in the system and this sometimes causes an initialisation
failure. An operational integrity violation points to a refresh not starting up properly. An
engineer was sent out to sort the base unit and node. It is worth noting that all messages
will be copied from the other node. Potentially could lose some information if the two PCs
nodes were not communicating at the point of breakdown. There was nothing to suggest
there was a problem at the end of the previous day this can be checked by looking at the
end of day marker to 1 February. AC stated that if it is a problem can forensically check the
old hard drive but you would need the postmaster to be aware of transactions having been
lost.
CALL LOG NO 402130261- 13.02.04 - This was bounced to NBSC.
CALL LOG NO 402130267-13.02.04 - Here NBSC bounced to HSH. AC looked at this one
and seemed to an issue of using a different drawer ID (ie doubling up).
Note: With regards to cheque listing he REMd out the cheques and then the cut off line.
We need to check the operational procedure for this matter.
You would expect to see all cheques and an empty report. It appears that the postmaster
forgot to cut off and the cheque listing had two days worth of cheques in it. There is no
option to cut off retrospectively, ie if the PM realises that he had not cut off the previous
days cheques they will show up the next day and the failure to cut off previously cannot be
corrected later . The system does not put cheques in the balance and process twice it will
reconcile that cheque against that transaction. With regards to rem stock in and getting a
loss - we do not know how much stock he received only what he entered at Post Office
Limited will know how much he gets sent. RIDC - rem in from distribution centre - a list of
what he was sent in may be kept. Every week he will do a rem stock in and ithe balance is
wrong iif he books the wrong quantity, may result in the amount being wrong.
Cheques were not cut off on the 10%.
CALL LOG NO 402160081- 16.02.04 - POLON - This is Post Office Log On usually due to a
powercut. PM will not usually see this screen.
CALL LOG NO 402160628 - 16.02.04 - OBCS check. This is the specific bar code reader
and is the order book control system a stop list of pensions that are not to be paid. The on-
line look up fails, PM should make a phone call.
CALL LOG NO 402250454 - 25.02.04 - This is regards ID declaration numbers with the loss
put into suspense. The balance sheet will show the old discrepancy until they can do a trial
balance and here they said they did a trial balance. AA = a stock unit. A link reported by
the clerk does not mean there is an actual link.
CALL LOG NO 402250553 - 25.02.04 - This is an NBSC referral, Wednesday reproducing
weekly cash accounts.
CALL LOG NO 402250565- 25.02.04
CALL LOG NO 402251011 - 25.02.04 - This is a critical event and is caused by not the PM
calling the helpdesk but by the SMC (system management centre) will call automatically if
there is an unusual event. Effectively this is stating that PM claims he has a major problem
and is at the point at which AC will enter the investigation.
CALL LOG NO 402251077 - 25.02.04 - PM stated that all the problems have been caused
since the BT engineer moved the box. KEL is a known error log and a reference number and
5
1A.1173514_2
POL00071427
POL00071427
may be logged on a previous event. In this context a storm is a central problem causing lots
of event storms. Various built in checks occur at the end of the day. For example the
gateway terminal will add all the transactions. The gateway terminal will only send in
information from these built in checks once all the terminals in the post office have
communicated with it. Reports are only produced if there are discrepancies. A weekly cash
account is produced and sent to the date centre. The gateway will do daily cash accounts.
This is summarised weekly and compared to the weekly branch cash account to check for
discrepancies. The data centre also produces a weekly cash account which is compared to
the branch weekly cash account. Therefore there are effectively 3 weekly cash accounts:
1. The branch weekly cash account.
2. The branch daily account which is accumulated at the week end.
3. The data centre weekly cash account.
AC checked the discrepancies between 1, 2 and 3 and found none. Cheques were handled
correctly (as far as the system is concerned). She checked the REM was correct, which it
was except for one day when he forgot to cut off the cheques but she only checked back one
week. She also noted that once in a while the declaration number was used incorrectly. For
example if you used 01 for £10,000 and then 11 for another £10,000 the system will think
that the branch has £20,000 but it only has £10,000. The daily cash handling were using a
double declaration number but this does not affect the weekly balance. AC went through
the transactions day by day and compared with the overnight declarations. You would
expect:
(a) a starting cash position
(b) transactions
(c) a system cash figure which should be close to the actual cash holding.
AC was taken aback to discover that (c) was way out every day, above and below. There
should be somewhere the other part of that transaction and what is on the system does not
match what is in the drawer.
There is no systems reason to explain the discrepancy. There is nothing to indicate a
computer system failure or the PM had an operational problem. There may be some
rounding up money to the nearest £1,000. You would never know what he was declaring
was right or wrong until the auditors goes out. An audit will take place upon the handover.
If he is declaring wrong it is not blindingly obvious to the sender. The system cannot tell if
the postmaster is concealing and will never know unless it is audited. Although people do
monitor cash holdings.
It was AC's feeling that it was sloppy inaccuracies rather than fraud. Additionally as the PM
is actually declaring the discrepancies this gives an impression of incompetence. It is AC’s
conclusion that there was no evidence of a system problem. It was only if the payments and
the receipts matched and there was no systems problems. AC looked at the week including
10 February. AC felt help was needed from an operational point of view and therefore the
call was passed back through Post Office Limited.
CALL LOG NO 403040165 - 04.03.04- RLM is a retail line manager (Fujitsu staff member).
CALL LOG NO 403040524 - 04.03.04
CALL LOG NO 403230583 - 23.03.04 - On 27 March CPM was suspended.
CALL LOG NO 403230628 - 23.04.04 - OSP is One Shot Password and is issued so the
auditor can log into the system.
CALL LOG NO 404010718 - 01.04.04 - New postmaster appointed.
CALL LOG NO 404190387 - 19.04.04 - Powerhelp is a recording system.
CALL LOG NO 404210187 - 21.04.04
CALL LOG NO 404210701 - 21.04.04 - There was an SMC call and a software upgrade.
Note: ASDL was switched on this time.
CALL LOG NO 404230660 - 23.04.04 - This was passed back to NBSC, Castleton raising the
call asking for documents. This was after he had been suspended and was obviously an
6
1A.1173514_2
POL00071427
POL00071427
POL00071427
POL00071427
attempt to get hold of particular documentation. It was further noted at this point that PM
was also advised to run a manual system.
SJD3 asked if there was anything else Fujitsu would have done.
The response was no and it was also noted that the new PM was using the same kit as Lee
Castleton was with no losses.
ARB3
1A.1173514_2