POL00021846 - Draft of Section 14 of Second Sight’s Interim Report

Evidence on official site

POL00021846

POL00021846

14. Transactions not entered by the Subpostmaster or their staff

14.1,

14.2.

14.3.

14.4.

14.5.

14.6.

14.7.

Many Applicants have reported that Horizon transactions appeared to have been entered,
or cash or stock balances changed, when the branch was closed and no one had access to any of
the Horizon terminals.

Post Office has stated that it is not, and never has been, possible for anyone to access
Branch data and amend live transactional, cash or stock data without the knowledge of
Subpostmasters or their staff. However, we are aware that certain error recovery and
correction processes can result in transaction reversals that carry the System Identity (ID) of the
user who entered the originating transaction that the system itself is reversing, or the ID of the
user restarting the system (see Section 15 ‘Transaction Reversals’).

We note that this fails to easily differentiate between entries made by a user and those that
are system generated.

One Applicant to the Scheme has given evidence relating to a facility in the Bracknell office
of Fujitsu where he alleged that he was informed that it was possible to alter Horizon
transaction details without the knowledge of individual Subpostmasters. We have requested
that the relevant email files from the period in question be provided to us in order to
investigate this matter, but so far Post Office has only provided us with a small number of the
files requested. Our review of those files has been inconclusive, possibly due to just one month
of data being provided, rather than the 12 months requested. We believe that it is essential to
examine contemporaneous documents from the relevant time, in order to form a reliable,
evidence based, conclusion on this important issue.

Several Applicants have stated that they believe (or suspect) that their branch terminals
have been, or can be, accessed remotely or that their branch data can be amended without
their knowledge or approval. Post Office has denied that it is possible to "amend branch data
remotely". It says that it does have access to branch data, but ina ‘read only’ format. It has
also stated that, if errors are spotted in the transaction data, the only way to amend the data is
to issue a TC or a TA to the branch and that only when the branch ‘accepts’ that TC or TA is the
branch's data amended.

We note, however, that Post Office has disclosed an October 2008 internal memorandum
that included the remark:

“Fujitsu have the ability to impact branch records via the message store but
have extremely rigorous procedures in place to prevent adjustments being
made without prior authorisation - within POL and Fujitsu".

At the time of our writing this Report, Post Office has not explained whether or not that
quoted statement was true at the time or whether, if it was true at the time, no such facility
currently exists, as it seems to be asserting.
POL00021846
POL00021846

14.8. In our Interim Report we referred to a software bug in Horizon that had impacted a small
number of branches. We have recently discovered two further documents that describe in
more detail how Post Office handled this issue. In both of these documents a process is
described that involves directly altering branch data. The fix for the error reported in the
document named “Correcting Accounts for “lost” Discrepancies”, created by a senior engineer
at Fujitsu in September 2010, stated:

“7. Fixing the Data for each Affected Branch

The data can be corrected by adjusting the appropriate Opening Figures and BTS
Data that relates to the current TP. This will result in the Discrepancy needing to be
processed when rolling over into the next TP.

I propose that if we are to do this then we take a copy of the data for one branch and
check out the proposed changes on a test system and then rollover the branch on the
test system to ensure that the discrepancy is handled correctly before we attempt to
correct Live data.

Having done one example in this way, we then need to agree a timetable with Post
Office Ltd to correct the other branches and ensure that this is communicated with
the Branches to ensure that everyone involved is happy. Note that if it is decided not
to correct the data in the branches (i.e. POL would prefer to write off the "lost"
discrepancy), then adjustments will be required to the Discrepancy account in
POLSAP to align this with the actual level of discrepancy seen at the Branches.”

14.9. This document refers to correcting live data - a procedure that Post Office denied was
possible. Of potential significance is the fact that this was not just an internal document made
available to a small number of Fujitsu employees, as the copy we were provided with was
printed out by the head of Post Office’s Legal Prosecution team in October 2010.

14.10. A further document titled “Receipts / Payments Mismatch issue notes” appears to be a
Minute of a joint Post Office meeting probably held in August 2010. The document refers to the
impact of the bug in Horizon as being:

“Impact

* The branch has appeared to have balanced, whereas in fact they could have a loss
ora gain

* Our accounting systems will be out of sync with what is recorded at the branch

¢ If widely known could cause a loss of confidence in the Horizon System by branches
* Potential impact upon ongoing legal cases where branches are disputing the
integrity of Horizon Data

* It could provide branches ammunition to blame Horizon for future discrepancies"

14.11. The Minute reported three possible solutions.

“Proposal for affected Branches

There are three potential solutions to apply to the impacted branches, the groups
POL00021846

POL00021846

recommendation is that solution two should be progressed.

SOLUTION ONE- Alter the Horizon Branch figure at the counter to show the

discrepancy. Fujitsu would have to manually write an entry value to the local branch
account.

IMPACT - When the branch comes to complete next Trading Period they would have a
discrepancy, which they would have to bring to account.

RISK- This has significant data integrity concerns and could lead to questions of
"tampering" with the branch system and could generate questions around how the
discrepancy was caused. This solution could have moral implications of Post Office’
changing branch data without informing the branch.

SOLUTION TWO - P&BA will journal values from the discrepancy account into the
Customer Account and recover/refund via normal processes. This will need to be
supported by an approved POL communication. Unlike the branch "POLSAP" remains
in balance albeit with an account (discrepancies) that should be cleared.

IMPACT - Post Office will be required to explain the reason for a debt recovery/
refund even though there is no discrepancy at the branch.

RISK - Could potentially highlight to branches that Horizon can lose data.

SOLUTION THREE - It is decided not to correct the data in the branches (i.e. Post
Office would prefer to write off the "lost"

IMPACT - Post office must absorb circa £20K loss

RISK - Huge moral implications to the integrity of the business, as there are agents
that were potentially due a cash gain on their system”

14.12. Although it would appear that “SOLUTION TWO” was the adopted solution, it is clear from
“SOLUTION ONE” that Fujitsu have the ability to:

“manually write an entry value to the local branch account”.
14.13. The risk of adopting this possible solution was described as:

"RISK- This has significant data integrity concerns and could lead to questions of
"tampering" with the branch system and could generate questions around how the
discrepancy was caused. This solution could have moral implications of Post Office’
changing branch data without informing the branch."

14.14. This ability to directly amend branch records is something that Post Office has consistently
denied was possible. This recently discovered evidence appears to confirm, that in 2010 at
least, it was possible for Fujitsu / Post Office to directly amend branch data without the
knowledge of the relevant Subpostmaster.

14.15. Clearly, the fact that such an ability exists, is not necessarily evidence that such amendments
were actually made. This is not something that we have been able to investigate.