POL00031516 - DRAFT INCOMPLETE Memo outlining conclusions from procedures performed as outlined in Change Order Number 06

Evidence on official site

POL00031516
POL00031516

DRAFT INCOMPLETE Memo outlining conclusions from procedures performed as outlined in Change Order Number 06 (Version 1).

(a) Project scope, objectives and background

Background

POL continues to respond to allegations that the “Horizon” IT system used to record transactions in POL branches is defective and the
processes associated with it are inadequate (the “Allegations”). In response to recent formalisation of these accusations into
commencement of litigation proceedings, Deloitte has previously been instructed to plan and execute procedures against three scope areas
to provide assurance that the Horizon system operates as expected, and there are reasonable controls and safeguards in place to prevent
incorrect system operation that could have resulted in Sub-postmaster detriment.

We have conducted ‘Phase 0’ a planning phase in which we performed interviews and documentation reviews in order to assess the
procedure options in the delivery of ‘Phase 1’ and we have also conducted ‘Phase 1’ in which we performed those procedures. Following
this ‘Phase 1’ of work we have also conducted a further planning phase ‘Phase 2’ in which we have conducted further planning and formative
procedures against particular scope areas, and ‘Phase 3’ in which further procedures against particular scope areas have been performed.

Scope and Objective

This additional phase of work will constitute ‘Phase 3b’, the ‘Non-Counter Transactions Phase’ whereby Deloitte will perform procedures
agreed with POL in relation to Non-Counter Transactions to provide an assessment as fully as possible in the time allotted by the
exercise, on the factors to consider, controls and risks, in answering the following questions:

1. Are there any gaps in the controls around Non-Counter transactions that could call into question the Integrity of the data
generated in relation to these transactions?
2. If there are gaps:
a. Could they be the cause of discrepancies in branch accounts (or could they mean that errors in Horizon would not be
revealed and those errors could then be the cause of discrepancies in branch accounts); and
b. What is the risk of those gaps (or resulting discrepancies) materialising?

The procedures to be performed are as follows:

1. Initial Workshop to corroborate understanding of data flows and validate the existence and completeness of controls over the current
reconciliation process and how Transaction Acknowledgements are utilised.

2. Review and test key reconciliation controls between key data sources within the data flow as highlighted within separate table (Appendix
1)

3. Perform detailed walkthrough of the Transaction Acceptance (TA) process to confirm the granularity of the information the Postmaster
is provided with. Perform procedures to corroborate a TA is required for all Non Counter transactions.

INCOMPLETE DRAFT - For discussion purposes only. 1
POL00031516
POL00031516

4. Analytics pilot to assess feasibility and then perform reconciliation between raw data files received by PODG and the interpretation of
these non-counter transactions into the BRDB transaction files.

(b) Deliverables
Our deliverable for Phase 3b will be a memo outlining work performed and conclusions and providing an assessment, as fully as possible
within the time allotted to this exercise, on the factors to consider, controls and risks in answering the questions POL has posed.

Usage of our Deliverables
For the avoidance of doubt, our deliverables, are for the use and review of POL only, and are not permitted to be shared with any other
third party without Deloitte’s prior written consent.

DELIVERABLE
Please find below the four scope areas as outlined in the statement of work, and responses to them in red:

1. Initial Workshop to corroborate understanding of data flows and validate the existence and completeness of controls over the current
reconciliation process and how Transaction Acknowledgements are utilised.

This workshop was performed with Fujitsu on the 9'* May 2017. Attendees from Fujitsu were:

Pete Newsome ~ Fujitsu, Post Office Account Manager
Torstein O’Godeseth ~ Fujitsu, Horizon Systems Architect
Russell Norman — Fujitsu, Project Manager

Pete Jobson ~ Fujitsu, Horizon SME

As a result of the workshop the understanding that Deloitte had originally obtained on the operation of the interfaces between the
systems was validated with a couple of amendments. The attached diagram displays the finalised viewpoint in relation to the dataflows.

As part of this review the decision to exclude ATMs from scope as Non-Counter Transactions was examined and it was highlighted by
Fujitsu that all interactions between ATMs and the Counter/BRDB are by rekeying of the data — i.e. this is not a system driven process.
Therefore the original decision to exclude ATMs from scope was adhered to.

2. Review and test key reconciliation controls between key data sources within the data flow as highlighted within separate table (Appendix 1)

INCOMPLETE DRAFT - For discussion purposes only. 2
POL00031516

POL00031516

Fujitsu discussion highlighted that one of the controls identified for potential testing was only operated temporarily during the switch

from Riposte to the Branch Database, and as a result no control exists to test in the present day. The remaining two controls are

legitimate controls to test, as they are currently worded, and one requires a wording tweak in order to test.

The below table captures the controls in scope, and the required updates to the original control wording where required:

Summary Control Wording

External transactions sent via PODG such that the External
Transaction files that are currently sent from Ingenico
(PAYSTATION) and Wincor Nixdorf (POST&GO) are routed to the
Branch Database as well as sending the data to the Credence
system. There is a reconciliation between Credence and BRDB.

Wotan existing control. [PS ~ BRDB is a rec, not Credence ~ BRDB.

Ipdate final sentence of control wording to ‘There is aj

econciliation between TPS and BRDB.’.

we

For each Transaction Acknowledgement generated, a new
transaction pair is created for POLSAP. The transaction delivered
to POLSAP will have a Reference number that matches the reference
number used in the Transaction Acknowledgement record
generation. This allows POLSAP to match with the Transaction
Acknowledgement once the TA has been accepted by the Postmaster.

‘ontrol exists.

30

AP Client File Reconciliation

APSS2222.ksh will reconcile the data in the files that it delivered to
a Client with the data in the files that Credence delivered to a
Client.

No longer an existing control ~ no further testing to be performed.

TPS to AP Reconciliation

TPSC227 writes APS transaction data to a formatted file that will
later be used by the APS host program APSC2051 to reconcile
data from TPS with that from APS.

Tontrol exists.

The results of the testing of these controls is documented below:

TO BE ADDED WHEN COMPLETED.

3. Perform detailed walkthrough of the Transaction Acceptance (TA) process to confirm the granularity of the information the Postmaster is
provided with. Perform procedures to corroborate a TA is required for all Non Counter transactions.

INCOMPLETE DRAFT - For discussion purposes only.
POL00031516

POL00031516

Detailed analysis of the TAs process was conducted through the following steps:

)

ii)

iii)

iv)

Review of Horizon Online functionality within the Model Office at Finsbury Dials on xx/yy/zzzz with assistance from Mark
Underwood and Phil XXX.

Confirmation via review of the system screens that the Horizon system included TA functionality relating to all of the non-counter
transaction areas under review, including:

a. Post and Go;

b. Paystation; and

c. Camelot.

No evidence was witnessed during this review, that there were other transaction types for which TAs would apply, although this
should not be construed by the reader to categorically mean other NCTs for which Transaction Acknowledgements would be
processed do not exist. To provide fuller assurance over the completeness of the transaction population for which TAs are
produced and relevant a detailed review of product types, and the related population of transaction types, would be required,
and this was beyond the scope of this piece of work.

Walkthrough of the receipt and processing of Transaction Acknowledgements on the Model Office test system. This walkthrough
highlighted the following key points: -

1. On Receipt of a TA the postmaster is able to review both at a header and line level of granularity.

2. On Receipt of a TA the postmaster must complete the processing of it, before trading can continue.

3. If the postmaster disputes the TA, then the TA ID should be noted to dispute with the helpline after the TA is processed (this
could then trigger a further Transaction Correction).

Review of the Model Office counter for each of these transaction types, in particular the Horizon Online Help Guide pages (which
are available within the system to all subpostmasters, confirmed that various reports on the balances are available to allow
reconciliation between the terminals involved and the TAs received and values within the Branch Database, as well as guidance
on the usage of TA functionality. Below is a summary of the findings against each of the three transaction types which have been
represented by Fujitsu and Post Office to formulate the population of Non-Counter transaction types for this work.

Paysta TAs
The following sections of the Horizon Online Help Guide were reviewed:

‘Paystation Transaction Acknowledgements’
This is a ten page document which upon review provides guidance on:

INCOMPLETE DRAFT - For discussion purposes only. 4
Ne

OP Ww

POL00031516
POL00031516

What TAs are. (Page 1)
Accounting for TAs (page 2)
¢ Including having to reconcile / check against all paystation transactions.
Non Receipt of TAs (Page 3)
Receipt & Processing TAs (page 6)
Including guidance on checking/reconciling the TAs against paystation transactions
Office Daily Reports (Page 9)
e Including details of a ‘Outstanding & Processed TAs’ report that is available
e This report gives detailed information on all TAs that have been received over the last 40 days and their existing
status.
e “There are no audit requirements for you to print and retain this report. However you may find it useful if you
need to verify information contained within the TAs against any terminal reports”

‘Accounting and Balancing Instructions for Paystation’
This is a four page document, which upon review provides guidance on:

1.
2.

What a TA is (page 1)
Reconciling transactions from Paystation against the TAs

Post and Go TAs
The following section of the Horizon Online Help Guide was reviewed:

‘Transaction Acknowledgements for Post & Go’
This is an eight page document which upon review provides guidance on:

1.
2.

3.
4.

What a TA is in relation to Pay & Go (Page 1)

Daily processing of a trading report at close of business & prior to business the next day to compare against TAs

received. (Page 2 & 3)

Non Receipt of TAs

Receipt and Processing of TAs (Page 6)

« Including recommending all Post & Go transactions are checked/reconciled against the TAs received.

Office Daily Reports (Page 7)

« Including details of a ‘Outstanding & Processed TAs’ report that is available:
This report gives detailed information on all TAs that have been received over the last 40 days and their existing
status.
“There are no audit requirements for you to print and retain this report. However you may find it useful if you
need to verify information contained within the TAs against any terminal reports”

TA Accounting Arrangements (Page 8)

e Including recommendation to check and reconcile the cash against the TAs received the following working day.

INCOMPLETE DRAFT - For discussion purposes only. 5
POL00031516
POL00031516

Camelot TAs
The following section of the Horizon Online Help Guide was reviewed:

‘Transaction Acknowledgements for Camelot’
This is a three page document which upon review provides guidance on:
1. What a TA is. (Page 1)
2. Accounting instructions for TAs
- Including check and reconcile the cash against the TAs received the following day (Page 2)

3. Non Receipt of TAs (Page 2)
4. TA report (page 3)

Additional Sections of Horizon Online Guide Identified as of Relevance
In addition to the above it was confirmed that there is a help page within Horizon Online Help providing contact details which
subpostmasters can use should they have issues with Transaction Acknowledgements for Paystation. This page was entitled
Contact Names, Addresses and Telephone Numbers’ and was two pages long.

v) To supplement these procedures further a review of additional sources of process narrative and guidance were obtained and
reviewed from POL staff. The documents reviewed as part of this further exercise were:

‘Self Serve Kiosk User Guide V4.1’

‘HNG Branch Trading Reports 310317’

‘HNG BT Balancing and despatch of docs 310317’
‘HNG Camelot Lottery On-line games 030417"

‘HNG Camelot Scratchcard games 030417’

‘HNG Cash and Secure Stock Rem Services 310317’
‘HNG Equipment and Admin Pages 310317"

eeece ses

Review of these documents, highlighted a number of areas which provided additional context/assurance:

Guide ‘HNG BT Balancing and despatch of docs 310317’
This document makes reference to.an ‘Office Snapshot Report’ and details how to create the report, but does not explicitly say
this can be used to reconcile against TA’s:
a. ‘Producing the Office Snapshot report to list stock and cash on hand and all the transactions carried out during the
current Branch Trading Period up to the time the report was requested, for all stock units in your branch.’ (Page 109)

INCOMPLETE DRAFT - For discussion purposes only. 6
POL00031516
POL00031516

Guide ‘HNG Camelot Scratchcard games 030417°
This document has a section that details account of scratchcards. This section highlights that National Lottery transactions are
accounted for via Transaction Acknowledgements and that a Camelot terminal creates a report which shows:

b. The total daily scratchcards sales

c. The daily prize payments

d. Any returns

e. Commissions (this figure will always be zero)

However the guide does not explicitly say that this report that shows all NCTs for National lottery should be reconciled against
the TA which accounts for National Lottery transactions.

(c) Recommendations on the further work to be performed in relation to Non-Counter Transactions.
1. In branch running of live reports and demonstration they can be used to verify that TAs match to records of activity on the respective

terminal.
2, Review of training materials courses available to SPMs, to support communication of these mechanisms to them.

INCOMPLETE DRAFT - For discussion purposes only. 7