POL00022666 - Extracts from Bond Dickinson to Freeths re: Defects in Horizon
A.
4.41
1.2
1.3
1.4
B.
1.5
1.6
POL00022666
POL00022666
Defects in Horizon
The Letter of Claim does not present any evidence of there being a systemic flaw in Horizon
that has wrongfully caused loss to postmasters. Even Second Sight, in its final conclusion to
its Part Two Report, could only make the weak point that:
“when looking at the totality of the ‘Horizon experience’ we remain concerned that in some
circumstances Horizon can be systemically flawed from a user’s perspective."
This is a long way short of saying that there is a problem with Horizon’s data handling
processes that create false entries in branch accounts resulting in false shortfalls and
wrongfully causing postmasters to suffer losses, for which they were improperly held liable by
Post Office. Second Sight never identified such a problem. We do not know what is meant by
the phrase "from a user's perspective". If this is intended to mean that certain individuals may
subjectively believe Horizon to be flawed, this is not evidence of a flaw. If it is intended to
mean that Horizon is not as easy to use as some users might like, this does not constitute a
breach of contract. Either way, even if it constituted evidence (which it does not), this point
would not be an adequate basis on which to mount a Court action.
You also refer to a number of historic "bugs" that you say Second Sight identified. This
characterisation is incorrect — Post Office identified these issues and it pro-actively resolved
them in accordance with its usual operating practices. No evidence has been presented to
suggest that these issues had any effect on the Claimants. To attempt to dispel any myths
around these issues, we have provided full details of them in Schedule 6.2
If you wish to maintain a claim that there is a systemic defect in Horizon that has wrongfully
caused loss to postmasters, it is incumbent upon you to identify the defect, explain what it
does and what consequences it has had for your clients. At a minimum, your clients would
need to precisely identify the transaction(s) or entries in the branch accounts that they
consider to be wrong. You should properly set out that claim and explain the evidence that
supports it. Your Letter of Claim does not begin to do this. We put you on notice that our
client will challenge any statements of case that do not properly identify and particularise a
claim of this nature.
Data integrity and remote access
The Letter of Claim makes a number of imprecise references to the idea that Horizon does not
accurately record branch transactions and / or that Post Office has edited branch transaction
data so to make it inaccurate.? We repeat our above points about the need for your clients to
provide proper particulars of allegations if they are to be maintained, in particular you have not
put forward any evidence that Horizon has inaccurately recorded a transaction or that Post
Office has manipulated Horizon data in relation to any of the Claimants or otherwise.
There are a number of controls and processes in place to protect the integrity of data within
Horizon. These include:
1.6.1 Each basket of transactions must balance to zero (i.e. the value of goods and
services vended must match the payments made / taken from the customer)
otherwise the basket will not be accepted by the counter terminal in branch. This
ensures that only complete baskets are recorded.
1 Paragraph 26.8, Second Sight's Briefing Report — Part 2
2 To be clear, we are not saying that these issues are an exhaustive list of the "bugs" that may exist in
Horizon. They are however the ones on which you rely and so we have addressed them in detail.
3 At paragraphs 5.7, 44.4, 46, 57, 125, 127.4 and 153.5 of the Letter of Claim
POL00022666
POL00022666
1.6.2 Counter transactions are committed automatically (i.e. a transaction is either
successful in its entirety or it is not successful at all).
1.6.3 A unique Journal Sequence Number is applied to “digitally sign” every counter
transaction. This allows missing or duplicate transactions to be detected and
remedied.
1.6.4 A master record of transaction data is stored in a central "audit store" which has
controls to ensure the permanency of data and a data retrieval process which
validates data integrity.
17 The majority of transactions that make up the branch accounts are generated in branch.
There are however four ways in which Post Office (or Fujitsu on Post Office's instruction) can
influence those accounts:
4.7.4 Transactions originating at Post Office. A number of "transactions" are
generated by Post Office and sent to branches, namely transaction corrections,
transaction acknowledgements and remittances of cash / stock into a branch.* A
key feature of these transactions is that they must be approved in branch (by the
postmaster or his assistants) before they form part of the branch accounts.
1.7.2 Global Users. Global Users are setup by default on Horizon in every branch.
These are user accounts for Post Office staff to use when undertaking activity in a
branch, such as training or audits. It is possible for these Global Users to conduct
transactions within a branch's accounts. However, this access is only possible if the
user is physically in the branch using a local terminal and the transactions are
recorded against the Global User ID.°
1.7.3 Balancing transactions. Fujitsu (not Post Office) has the capability to inject a new
"transaction" into a branch's accounts. This is called a balancing transaction. ® The
balancing transaction was principally designed to allow errors caused by a technical
issue in Horizon to be corrected: an accounting or operational error would typically
be corrected by way of a transaction correction. A balancing transaction can add a
transaction to the branch's accounts but it cannot edit or delete other data in those
accounts. Balancing transactions only exist within Horizon Online (not the old
version of Horizon) and so have only been in use since around 2010.’ Their use is
logged within the system and is extremely rare. As far as Post Office is currently
aware a balancing transaction has only been used once® to correct a single
branch's accounts (not being a branch operated by one of the Claimants).°
1.74 Administrator access to databases. Database and server access and edit
permission is provided, within strict controls (including logging user access), to a
small, controlled number of specialist Fujitsu (not Post Office) administrators. As
far as we are currently aware, privileged administrator access has not been used to
alter branch transaction data. We are seeking further assurance from Fujitsu on
this point.
4 See paragraph 7.16 onward in Second Sight's Part One Report for a more detailed explanation of
these processes.
5 Strictly speaking, the Global User ID should be used to generate a new unique ID for the Post Office
staff member and the new ID would then be used for training, audits, etc.
6 The use of balancing transactions was explained to Second Sight and is referenced in its Part Two
Report at paragraph 14.16.
7 Post Office is making enquiries as to whether something akin to a balancing transaction existed in
Horizon before the upgrade in 2010.
® This was in relation to one of the branches affected by the "Payments Mismatch" error described in
Schedule 6.
° Several hundred other balancing transactions have been used but not in a manner that would affect
branch accounting. These were generally used to "unlock" a Stock Unit within a branch.
1.8
1.9
POL00022666
POL00022666
Ultimately, no postmaster going through the Scheme was able to point to a particular
transaction that they believed had been created, edited or deleted by Post Office without their
knowledge. Moreover, you have presented no evidence that misuse of any of the above
processes by Post Office was the cause of any shortfall in any Claimant's branch.
Post Office maintains that the combination of technical controls in Horizon and operational
controls at Post Office and in branch (including the need for postmasters to diligently monitor
their branch accounts, cash and stock as described in Schedule 4) provides satisfactory
assurance that Horizon does accurately record the transactions input by the Claimants (or
their assistants).