POL00071414
POL00071414
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), Hugh James (HJ), Brian Pinder (BP), Peter Sewell (PS) Andy Dunce (AD) of Fujitsu
Graham Ward (GW) of Post Office Limited (POL)
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
from 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 loggers website.
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 technical, a user or hardware issue. BP can
produced technical people to explain how the system works. Essentially the computer
records every key press.
SJD requesting a summary of how Horizon works. GW stated that Michael Gallagher and
Tony Utkins 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. BP saying
essentially it records every transaction and key press. 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.
1A 1173050_1
Note: Helplines are :
The HAS helpline - this is for technical difficulties and is run by Fujitsu
The NBSC helpline - this is for procedural issues and is run by POL
AD stated that he had produced a statement which was a brief overview of calls received to
the helpdesk and how they were responded to. AD doesn’t know about the technical aspects
of this.
MH said 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 automatic and log
automatically, usually this is out of hours.
BP asked if work is done on the system overnight, critcal events can occur on the systems.
Gareth Jenkins (GJ) enters the meeting.
SJD referring to the further information, the defence and the Part 20 claim and in particular
1.1A1 with the non-communication between the PCs.
G] said every transaction is committed to the local PC and written to that disk. It is also
copied to the other PC in the branch, directly to the disk if the communications are working -
if they are not working the systems will catch up later. The reporting is all done from the
data on the PC you are working on.
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 stack.
There is no chance of getting a partial session, you either get all of the session or
none of it.
Balance snapshots will not be accurate if the comms are not working at that time but they
will catch up the next time. 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 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.
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 will connect the centre. Each PC will detail all transactions on both PCs.
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.
Ann Chambers (AC) joined the meeting along with Naomi Elliott (NE).
SJD outlined the case to AC. SJD referring to the further information document 1.1(ii)
screen freezing.
G) said 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. The system will always reconcile itself.
For each session:
1A 1173050_1
POL00071414
POL00071414
POL00071414
POL00071414
(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.
(iv) card swipe - if it doesn’t read after 3 goes then the number is keyed in manually. 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 recorded. He should also know what cards are
supported or not.
Note: Check to see if there is a standard POL memo surrounding this issue.
(v) ONCH (overnight cash holding) - each day must have a cashed declaration identification.
If the branch use separate ID numbers the system will add the figures together, although
this does not affect the balance. The user is asked to enter a declaration identification
number and they usually enter the same number every day. 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. The system will highlight discrepancies. With
respect to the ONCH if you type 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 this is part of the
mechanism for ordering extra cash. If you type 1 on one machine and 2 on another the
system will add these together and he 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 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 cheque on
hand. The PM can print off a cheque report which can be corroborated to physical cheques.
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 cheque should
be as 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 you had handed out money and not taken a foil
then that is his problem but it was taking he could record it later.
1.2 (ii) detailed locally obtaining 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.
1A 1173050_1
POL00071414
POL00071414
Note: 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 relief picture but cannot count the actual cash in the
draw 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 ..... 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 .... 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. The trouble with the balance sheet for the 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.
Moving on to the 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. 1 -~ This is referring to the PMMC Card. This is used by PMs to log on to the
system.
CALL LOG NO 2 - This is referring to the ASD update from ISDN. This was a scheduled visit
and was for the board an update.
CALL LOG NO 3 - Referring to discrepancies 3 weeks in a row on 28 January.
Note: Need to check when Post Office went alive 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 4 - REM. These are remittances accepting new stock have ran out when a
cheque or cash leaves the systems. This call is bounced to MBSC.
CALL LOG NO 5 - At approximately 3.30 am 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 02. It is
worth noting that all messages will be copied from the other node. Potentially could lose
some information that the two 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 6 - This was bounced to MBSC.
CALL LOG NO 7 - Here MBSC 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 checklisting he ran 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 check listing had two days worth of cheques in it. There is no option but to cut
off belatedly. 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 the last - I 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 distribution
1A 1173050_1
POL00071414
POL00071414
centre ... with a list of what he was sent in may be kept. Every week he will do a
rem stock in and if the balance is wrong it will be why he had checked to the wrong
quantity may result in the amount being wrong. Cheques were not cut off on the
10th,
CALL LOG NO 8 - POLON - This is Post Office Log On usually 2 to a £1. PM will not usual see
this screen.
CALL LOG NO 9 - UBCS Check. This is the specific bar code reader and is the order book
control system and is a stop list of pensions that are not to be paid. The on-line hook up
fails PM should make a phone call.
CALL LOG NO 10 - This regards to 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 only reported by the clerk does not
mean there is an actual link.
CALL LOG NO 11 - This is an MBSC referral, Wednesday reproducing weekly cash accounts.
CALL LOG NO 12 -
CALL LOG NO 13 - 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 has a major problem and is at the point at which AC
will enter the investigation.
CALL LOG NO 14 - 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 may be logged on a
previous event. In this context a storm is an essential 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
running ..... is our only discrepancy. A week 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 weekend.
3. The data centre weekly cash account.
AC check the discrepancies between 1, 2 and 3 and found none. Checks were handles
correctly (as far as the system is concern). 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 will use a
double declaration number but this does ...... the weekly ......... 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 not systems reason to explain the discrepancy. There is nothing to indicate a
computer system failure although 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 audit 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 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
1A 1173050_1
POL00071414
POL00071414
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 15 - RLM is a retail line manager (Fujitsu staff member).
CALL LOG NO 16
CALL LOG NO 17 - ON 27 March CPM was suspended.
CALL LOG NO 18 - OSP is one for the password and is issued so the auditor can log into the
system.
CALL LOG NO 19 - New postmaster appointed.
CALL LOG NO 20 - Powerhelp is a recording system.
CALL LOG NO 21
CALL LOG 22 - There was an SMC call and a software upgrade.
Note: ASDL was switched on this time.
CALL LOG NO 23 - This was passed back to MBSC, he raising the call asking for documents.
This was after he had been suspended and was obviously an 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. His 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 1173050_1