POL00021781
POL00021781
Message
From: Parsons, Andrew [/O=BOND PEARCE/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=AP6]
Sent: 05/05/2015
To: Simon Clarke k
cc: Rodric Willi Loraine, Paul
C mneaaes GRO a noennee eee
BCC: 364065_00531 Horizon Challenges General E_Mails [{F20472253}.4A-LIVE, == SGRO- i
Subject: Balancing Transactions [BD-4A.FID20472253]
Attachments: NOTE TO POL - DELOITTE QUESTIONS 27-3.pdf; WI3649S.PDF; FW: Future Arrangements and Part Il; FW: Future
Arrangements and Part Il; Part 2 Report - FINAL VERSION - 9 April 2015.pdf; Response to Second Sight Part 2 report
FINAL.PDF; POL Response to P2 Report April 2015.pdf
Simon, Martin
A few weeks back we discussed the "balancing transaction" process used on Horizon and the effect this might have on
prosecutions. Simon then kindly sent through the attached questions.
Second Sight also raised a similar issue at around the same time though from a different perspective. For the sake of
completeness, I've attached:
Second Sight's original query — email from lan Henderson of 7 April
POL's response — email from Patrick of 8 April
The final SS Part 2 Report — see section 14 which sets out SS' views on this issue.
The POL response to the Part 2 Report —section 14.
I've set out below answers to Simon's questions. This information is taken from calls and emails between me / Mark (in
the Sparrow team) and Pete Newsome at Fu.
1. Is or would the use of the Balancing Transaction function, or any effect thereby achieved, be visible:
a) to an affected SPMR either:
i. upon the immediate occasion of its use; or
There is no technical notification to the SPMR via Horizon that a BT has been used. However, FJ say that
POL would only initiate a BT following discussions with a SPMR as using a BT is so unusual. This also
reflects discussions I've had with Rod Ismay (Head of POL FSC).
ii. at some point after use, e.g. by notification, appearance on Horizon, in branch accounts etc.
The BT would show as a transaction in the branch transaction records. However, these transaction
records are only accessible for the last 60 days (previously 42 days on old Horizon). Also, the transaction
would not be distinguishable as a BT as opposed to any other transaction input by the branch.
b) an auditor when conducting a branch audit?
Same as above as an auditor only has access to information held in the branch unless they request the
ARQ data - see below.
c) when data is provided to or obtained by a prosecution expert witness?
I don't know what data is provided to a prosecution expert. If this is the ARQ data then see (e) below.
d) when data is disclosed to a defence expert, for any purpose?
POL-0018260
POL00021781
POL00021781
I don't know what data is provided to a defence expert. If this is the ARQ data then see (e) below.
e) in the final audit trail?
By final audit trail, I presume you mean the ARQ data taken from the Audit Server being the master
record of transactions conducted on Horizon. The ARQ data does show the BT and has sufficient detail
(more than available in branch) to identify a transaction as a BT.
POL-0018260
POL00021781
POL00021781
ii. How and in what circumstances may the Balancing Transaction function be utilised?
Theoretically any situation but it is designed to correct errors in a branch's records. According to FJ, all
other forms of error correction (eg. transaction corrections, etc.) would be exhausted before using a BT.
iii. Who may use the Balancing Transaction function, in terms of authority, access, etc.?
Answer below from FJ:
If Post Office have a requirement for the Fujitsu SSC to update the Branch Database by injecting a balancing transaction
the process is:
Issue is described on a Peak incident (the incident reporting system)
Requirement for financial correction identified by Post Office and discussed with Sub Postmaster
Peak transferred from SSC to Development team to write required correction as a script
MSC generated and signed off by Post Office to provide audit trail and authorisation for change
Development upload script to MSC (previously OCP)
SSC verify script as attached to MSC, download and copy to live system
SSC change role from read only to read / write access
SSC perform the data correction
Any change would be a new transaction in the audit log and can be identified under a separate identifiable login
in the branch audit record. All existing transactions are unchanged.
e — It is Post Office’s responsibility to explain the need for the change and the change that took place with the Sub
Postmaster.
During all stages above marked “SSC” one member of the SSC will perform the action while a second member of
the SSC will witness ("four eyes rule" — see WI). Both names must be recorded on the MSC for audit purposes.
ee eevee ene
See document WI3649S attached which sets details of the "four eyes" safeguard operated by FJ.
iv. What measures, controls or processes are in place to routinely monitor centrally initiated Balancing
Transactions, and to check and reconcile data sources?
FJ do not routinely check for BTs since they are so rare. However, since the introduction of Horizon
Online, HOL automatically logs any use of a BT. This log can therefore be interrogated to identify if any
BTs have been used. Also, FJ could search the all raw ARQ data for BTs albeit that this would be a time
consuming process.
v. Similarly, what measures, controls or processes are in place to prevent any unauthorised use of the
Balancing Transaction function? Here we note the reference in the Deloitte Report to ,,fake™ transactions;
See above - in particular the four eyes rule and the fact that BTs are transparently shown in the ARQ data.
vi. What records are maintained of any use of the Balancing Transaction function?
See above - in particular the BT log but also there should be a paper trail that sits behind any BT in
accordance with the process described above.
vii. Is POL/Fujitsu sure that the Balancing Transaction function has only been used ona single occasion
since 1st January 2010? And if not, why not?
POL-0018260
POL00021781
POL00021781
FJ are sure that only one BT has been used since 1 Jan 2010 as only one BT has been recorded on the BT
log. Details of that incident (provided by FJ) are set out below.
The affected branch is not the in Scheme - branch details:
Bishopdown
j Bishopdown
Po
[Open
ez
Open’ ‘I Salisbury
[England Adres Wiltshire
08-Feb-13
One Stop Stores Ltd
Agency Branches
Background:
HNGX was being piloted early in 2010 and was deployed to a limited amount of branches. In March of 2010, an issue was
reported by a sub-postmaster that resulted in a duplicate transaction being generated when the application went off line
unexpectedly.
When the transaction correction tool is used as described below, it is completed in a unique auditable event is captured
in the audit trail and can be searched for in the audit archive. Only 1 event of this nature has been identified from
scanning all records since go live of HNGX.
The following timeline summarises the event.
2/3/2010: Error Occurs
While the Post Master was performing a cash transfer Horizon went offline unexpectedly. Horizon automatically
detected the failure and included a warning on the receipt that the results of this session would need to be checked by
the Sub Post-Master. The Sub Post-Master duly checked and discovered the transfer had been doubled.
4/3/2010: Incident raised
Helpdesk call raised by Sub- Post Master and sent to Fujitsu software support team for investigation
5/3/2010: Error confirmed
Fujitsu software support team confirmed the doubling up of the transfer. Work round design and root case analysis
started, Sub-postmaster informed of progress.
10/3/2010: Data fix script designed
Fujitsu software support proposed to repair accounts by insertion of auditable records into branch database to negate
the duplicate transaction
POL-0018260
POL00021781
POL00021781
11/3/2010: Data fix executed under change control
Change control raised and approved by POL (Emma Langfield — See Attached) — Sub-Postmaster informed.
Actions taken by Fujitsu software support while coordinating with Sub Post Master: A Balance Snapshot was taken
(showing the error), the Transaction Correction Tool was run by (inserting the negation records with appropriate logging)
and a subsequent balance snapshot was run. Post Master happy that accounts show the correct balance.
Output from the Transaction Correction Tool added to incident record.
12/3/2010: Fujitsu Software Support check effect of fix
Fujitsu software support checked the summarised accounts (produced overnight) for this branch to confirm that the
correction had been propagated correctly through the system.
Work round to correct accounts confirmed as complete.
04/04/2010: Root cause resolution
The problem was caused by a rare combination of circumstances that occurred in the early pilot phase for HNGX. A code
fix was made to remedy the root cause and implemented across HNGX via the BAU process.
Kind regards
Andy
Andrew Parsons
Managing Associate
Gov Die
mate GRO
Follow Bond Dickinson:
LS ]inI
www.bonddickinson.com
Mo!
Fax:
POL-0018260