POL00122393
POL00122393
Second Sight Horizon Investigation
Discussion Paper
April 2013
1. Purpose
1.1. In order to provide Second Sight investigative independence, Post Office is not in direct control of
the content, time scales or cost of the inquiry. As a result the investigation is at risk of continued
delays, cost overruns, and deviating from its original purpose. Unless contained the investigation
cost is likely to run to between £500k and £700k and provide no definitive outcome.
1.2. This report provides a recommended approach tighten control of the investigation and contain
scope.
2. Background
2.1. When Post Office commissioned Second Sight the expectation was that the investigation would
cover a small number of MPs cases (6 to 12 cases).
2.2. MPs have now submitted 29 cases
2.3. Second Sight and JFSA are asserting that the investigation should follow a different methodology,
rather than reviewing MPs cases, they believe the investigation should adopt a thematic approach
using spot reviews to examine potential failures.
2.4. Second Sight are now following a thematic approach (through spot reviews), whilst, in parallel,
continuing to investigate MPs cases. To date, Post Office has received four spot reviews.
2.5. It is unlikely that the investigation, no matter how long it runs, will conclude anything definitive,
as the remit has become blurred, and the evidence is open to interpretation.
2.6. There is currently no defined point at which the investigative process will end.
2.7. To date the investigation has cost £180k. At the current rate of spend, by December 2013 the cost
will be £500k, by next July the cost will be £750K .
2.8. The meeting with MPs on 25" March and subsequent correspondence gives Post Office an
opportunity to contain the scope.
3. Proposal
3.1. We use James Arbuthnot’s letter to Alan Bates dated 16th April, as a means to contain the scope
and timescales. This letter makes the following points:
3.1.1. Second Sight focuses their efforts on the two best MP cases.
3.1.2. A “result” — even if preliminary, by the summer.
3.1.3. He doesn’t respond to Alan Bates request to change the methodology to use a thematic
approach focusing on “systemic failures”
Strictly Private and Confidential; Subject to Legal Privilege 1 of 26
POL00122393
POL00122393
3.2. Paula or Alice set-up a meeting with James Arbuthnot to discuss and agree the following:
3.1.1.
Share our concern about the overrunning cost and time of the investigation, noting it has been
running for a year and to date no evidence of systemic failures have been found.
3.1.2. To move forward with the suggestion in James Arbuthnot’s letter and ask James Arbuthnot to
direct Second Sight complete two in-depth MP cases — selecting the ones that they feel indicate
systemic problems.
3.1.3.
3.1.4.
Ask James Arbuthnot to hold a meeting in June or early July for Second Sight to report back.
Ask James Arbuthnot to refine the remit to Second Sight to: determine if sub postmasters
have been wrongly convicted due to defects in the Horizon system.
3.1.5.
James Arbuthnot makes it clear to Second Sight and MPs that when the evidence is reviewed
in June/July, if there is no strong evidence that there was a miscarriage of justice the
investigation will be closed.
3.1.6.
We should consider providing James Arbuthnot a copy of the four spot reviews and our
responses, to give him a feel for the poor quality of the evidence that is being levelled against
Horizon after 12 months of investigation. (See appendix)
4. Stakeholder response
Stakeholder I Response Recommended Approach
James If James Arbuthnot is concerned about the I Build on common concerns.
Arbuthnot growing cost and scope of this Make sure he understands:
investigation, this gives him a good
opportunity to reign it in. 1. The implications of no
intervention (cost/time).
2. Quality of the evidence
gathered so far in the
investigation
3. Remit of the investigation
may now not be answering
the questions he thinks it is.
4. Only he can reshape the
direction of the investigation
as we can’ be seen to be
controlling it.
JFSA JFSA will respond negatively and will We need to make it clear to
probably redraw support from the James Arbuthnot that JFSA will
investigation. They will probably take their I respond negatively to the
views to the media. recommended course of action
to ensure that he is prepared for
It was always likely that JFSA would take I their response.
this course of action at some point in the
investigation. (unless Second Sight find a
Strictly Private and Confidential; Subject to Legal Privilege
2 of 26
POL00122393
POL00122393
major problem)
Second Sight Second Sight would like to take a thematic I If the direction comes from
approach as that produces the most James Arbuthnot, Second Sight
thorough outcome. They will see this as an I are likely to accept this change of
unwelcome restraint on their desired direction as they perceive him as
investigative process. the ultimate sponsor. They will
not accept this direction if it
comes from Post Office.
Strictly Private and Confidential; Subject to Legal Privilege 3 of 26
POL00122393
POL00122393
Appendix
We have received four spot reviews from second sight:
1. SROO1— Communication line failure - raised by John Armstrong the SPMR in Lepton Branch
2. SRO11- GIRO Payments and the apparent Loss of Audit Trail — raised by Tracy Ann Merritt in
Yetminster Branch
3. SRO12 - Missing Cheques — raised by Jo Hamilton in South Wanborough
4. SRO13 - Missing Cheque for a TV licence — raised by Jo Hamilton in South Wanborough
Below are the spot reviews, followed by the Post Office draft response
Strictly Private and Confidential; Subject to Legal Privilege 4 of 26
POL00122393
POL00122393
HORIZON — SPOT REVIEW 1
Reference Number: I SROO1 Issue Debit Cards — Cash Date: 04/10/2012 at
Type: Withdrawals and GIRO 10:32 hrs
payments
SPMR Name: John ARMSTRONG I PO Lepton FAD: 1913204
Branch:
Loss to SPMR? yes & No O Current I Awaiting response from I Category: I 1020
Status: POL
304m
What the SPMR says happened
The SPMR reports that there were intermittent internet connectivity problems (also reported to Chesterfield)
on 4 October 2012. Online payments and withdrawal transactions were sometimes successful but also failed
on occasions. It is possible that Horizon was partially operating through its back-up (mobile phone) connection.
Some card payments had to be attempted two or three times before being accepted. At approximately 10:32 a
customer tried to pay his £76.09 BT phone bill with his LTSB card but was not successful. The customer then
withdrew £80.00 cash and used this to pay the phone bill. The SPMR stamped the customer’s phone bill to
evidence receipt of the cash, returning change of £3.91. Several weeks later, the customer returned from
holiday to find his phone had been cut off due to non-payment. The SPMR’s examination of the Transaction
Log showed that all components of the transaction had been reversed. The SPMR did not initiate those
reversals nor did he receive any reversal notifications. The SPMR raised this as an issue with Chesterfield but
was told that due to cost issues Horizon transaction data could not be requested. It was implied that the SPMR
had stolen the money and he was told to make good the shortage. This meant that 2 people had paid the
phone bill (the customer, who handed cash to the SPMR and the SPMR on instructions from Chesterfield). The
SPMR was informed that he should have a surplus of £76.09 due to the reversal of the transactions. The SPMR
disputes this conclusion, but the more important issue here is the automated, unreported, reversal of the
transactions.
Investigative work done
© Dialogue with the SPMR and with POL seniors in order to clarify the facts
© Review of letter from P&BA dated 14 December 2012
* Review of Fujitsu XML-level data for October 4" 2012
POL Response
PRELIMINARY CONCLUSIONS
The Horizon automated recovery process designed to deal with power and internet failures reversed a series of
transactions without notifying the SPMR or reporting the actions performed on screen or elsewhere. The
system also failed to notify the SPMR of the appropriate corrective actions.
The decision by P&BA not to examine the Horizon detailed transaction data on cost grounds delayed or denied
the SPMR the opportunity to process the transactions correctly or understand what happened.
Strictly Private and Confidential; Subject to Legal Privilege 5 of 26
POL00122393
POL00122393
Horizon Spot Review - Response
SRO1: Debit Cards — Cash Withdrawals and GIRO Payments
1. Executive Summary
This Spot Review does not demonstrate any failing in Horizon.
This Spot Review principally asks whether a SPMR will be properly notified about automatic reversals
of transactions when Horizon is unable to connect to the Data Centre. The analysis below shows that
Horizon does provide adequate notification.
Further, in the particular case raised in the Spot Review, the root cause of the difficulties suffered by
the SPMR was his failure to follow the on-screen and printed instructions given by Horizon. Post Office
Limited is confident that the SPMR knew that some transactions had been automatically reversed
because:
e The branch had been suffering connectivity issues in the run up to the incident in question.
* When the transactions in question first failed to be processed (because Horizon could not get a
response from the Data Centre), Horizon asked the SPMR whether he wished to cancel or retry
the transactions. The SPMR opted to retry the transactions.
© When the transactions failed again, the SPMR opted to cancel the transactions.
* Horizon then automatically disconnected and printed a "disconnect" receipt that showed the
transactions that had been automatically reversed. A sample "disconnect" receipt is included
the appendix to this response.
e A standard customer receipt was not produced — this would tell the SPMR that the full
transaction had not proceeded.
e Following the disconnect, the SPMR was required to log back on to Horizon and duly did so.
e Following the log on, and as part of the standard recovery process, Horizon printed a
"recovery" receipt which again showed the transactions that had been reversed and those that
had been recovered. A sample "recovery" receipt is included in the appendix to this response.
2. Introduction
This spot review relates to an issue raised by John Armstrong the SPMR in Lepton Branch (FAD Code
1913204) relating specifically to transactions carried out on Horizon Online on 4" October 2012. The
issue is headed “Debit Cards — Cash Withdrawals and GIRO payments”.
This report provides information as to what was alleged by the SPMR (see section 3) and a detailed
analysis of what actually occurred as shown in the system logs (section 4). Section 5 then describes
how recovery operates on Horizon and Section 6 identifies those points in the report which are not
supported by the Logs. Finally section 7 addresses the question of access to raw transaction data.
3. The SPMR’s view of what happened
The following is an extract from the Spot Report saying what the SPMR says happened:
The SPMR reports that there were intermittent internet connectivity problems (also reported
to Chesterfield) on 4 October 2012. Online payments and withdrawal transactions were
sometimes successful but also failed on occasions. It is possible that Horizon was partially
operating through its back-up (mobile phone) connection. Some card payments had to be
Strictly Private and Confidential; Subject to Legal Privilege 6 of 26
POL00122393
POL00122393
attempted two or three times before being accepted. At approximately 10:32 a customer tried
to pay his £76.09 BT phone bill with his LTSB card but was not successful. The customer then
withdrew £80.00 cash and used this to pay the phone bill. The SPMR stamped the customer’s
phone bill to evidence receipt of the cash, returning change of £3.91. Several weeks later, the
customer returned from holiday to find his phone had been cut off due to non-payment. The
SPMR’s examination of the Transaction Log showed that all components of the transaction had
been reversed. The SPMR did not initiate those reversals nor did he receive any reversal
notifications. The SPMR raised this as an issue with Chesterfield but was told that due to cost
issues Horizon transaction data could not be requested. It was implied that the SPMR had
stolen the money and he was told to make good the shortage. This meant that 2 people had
paid the phone bill (the customer, who handed cash to the SPMR and the SPMR on instructions
from Chesterfield). The SPMR was informed that he should have a surplus of £76.09 due to
the reversal of the transactions. The SPMR disputes this conclusion, but the more important
issue here is the automated, unreported, reversal of the transactions.
From this information, the following key issues have been identified:
e When Horizon cannot get a response from the Data Centre, are automatic transaction
reversals notified to SPMRs?
e Why is raw transaction data not provided to SPMRs? It is noted that this second issue does not
raise a question about an error in Horizon. Rather, it is focussed on Post Office's procedures
and processes.
4. What the System Logs show
Note that the system logs show all times in GMT rather than local time. On 4" October 2012, GMT was
1 hour behind Local Time (ie BST). The times quoted in this review relate to the system logs. Therefore
the mention of 10:32 by the SPMR above relates to 09:32 in the logs.
There do appear to be 2 cases on 4" October where the system had a forced Log Out that resulted in a
recovery Log On being required. This supports the statement above: “The SPMR reports that there
were intermittent internet connectivity problems (also reported to Chesterfield) on 4 October 2012”.
The two “Recovery Log Ons” occurred at 08:51:40 (when no recovery was required) and at 09:37:20
when recovery was required as will be described later in this report.
The following table looks at the number of online requests for either Banking or Credit / Debit Card
Payments that appear to have timed out:
Date Total
04/10/2012 13
05/10/2012 4
08/10/2012 11
10/10/2012 2
11/10/2012 2
16/10/2012 1
17/10/2012 2
18/10/2012 2
3
1
1
2
19/10/2012
22/10/2012
23/10/2012
25/10/2012
Grand Total 44
This supports the comment regarding intermittent connectivity problems on 4" October. I note that
there were similar problems on 8" October.
Strictly Private and Confidential; Subject to Legal Privilege 7 of 26
POL00122393
POL00122393
There are 4 examples prior to 09:30 where either a Banking withdrawal or a Credit / Debit card
payment initially failed and was successful on the second attempt. There was also one example where
there were two failures for a card and presumably the customer or the SMPR gave up. This supports
the statements that “Online payments and withdrawal transactions were sometimes successful but
also failed on occasions” and that “Some card payments had to be attempted two or three times
before being accepted”.
The raw logs do have statistics regarding times taken to connect to the Data Centre and also an
indication of the type of Comms currently in use. From these it can be seen that the Branch normally
operates using ADSL, but at the time of the failure that is being examined it appears to be using a
mixture of O2G and O3G (ie mobile networks) presumably due to a failure of the main ADSL
connection. This supports the statement that “It is possible that Horizon was partially operating
through its back-up (mobile phone) connection”. This may have been visible to the user as a slower
than normal response time.
The key transactions are those described as occurring at 10:32 (ie 09:32 GMT).
This analysis starts at 09:26 and shows the sequence of baskets processed between that time and
09:40.
1. 09:26:30: Session 537799 contained two transactions: A Card Account Withdrawal (Withdraw
Limit) for £271.54 and a corresponding Cash Settlement.
2. 09:27:34: Session 537800 contained three transactions: A failed Card Account Withdrawal
(Withdraw Limit) immediately (09:28:13) followed by a successful Card Account Withdrawal
for £141.80 using the same card and a corresponding Cash settlement.
3. 09:29:27: Session 537801 contained a single transaction: A failed Visa Debit card payment.
This payment had been requested for £141 and had failed due to no response having been
received by the counter within the timeout period (33 seconds). Clearly an attempt had been
made to purchase something or pay for a service for £141, but when the Debit card payment
failed, the original transaction was voided and the basket completed.
4. 09:31:56: Session 537802 contained 2 transactions. A Halifax Current Account Withdrawal for
£200 followed by the corresponding cash settlement. It would appear that the card used here
was the same as the one used in the previous session when the Debit Card payment failed.
5. 09:32:52: Session 537803 contained 3 transactions. A bill payment to BT for £76.09 followed
by a Cash Withdrawal for £80 using a Lloyds TSB card and £3.91 cash for the difference.
6. 09:37:19: User JAROO1 Logged On again
7. 09:37:44: Session 537805 generated by the system as part of the Recovery that takes place
during Log On and contains 3 transactions. The first 2 are the Reversals for the BT Bill Payment
and Cash transactions in session 537803, and the 3" is a Cash balancing transaction for £80 to
correspond to the £80 cash withdrawal which should have been treated as successful at the
time of failure. This is why “The SPMR’s examination of the Transaction Log showed that all
components of the transaction had been reversed.”
It should be noted that the statement is not quite correct. The Banking Withdrawal for £80 has
not been reversed.
8. 09:40:19: Session 537806 contained 2 transactions. A Card Account Withdrawal (Withdraw
Limit) for £229.72 and a corresponding Cash Settlement.
It should be noted that there was no Session 537804. There are a number of circumstances under
which there are gaps in Session Sequence Numbers and in general they are not expected to be
contiguous. In fact they are based on an underlying Journal Sequence Number which are contiguous
and relate to any record that has been audited.
In this case the “missing” number relates to the Journal Sequence Number used in the Log On Request,
but there are a number of other circumstances that can result in a Journal Sequence Number being
used where there is no corresponding Basket.
Strictly Private and Confidential; Subject to Legal Privilege 8 of 26
POL00122393
POL00122393
Looking at the statistics recorded with the Recovery basket at Point 7 above, it can be seen that there
were a number of issues during session 537803:
a. The Authorisation for the Cash Withdrawal was successful and was done on a 3G comms
Connection.
b. The subsequent attempt to update the Recovery information in the basket after completing
the Banking Transaction failed due to a timeout on a 2G comms connection
c. There are then 4 attempts (at roughly 45 second intervals) to store the completed basket to
the Data Centre. The first 2 use a connection type of 2G and the other 2 use a 3G comms
connection. From the branches records, they are all marked as having failed.
d. From the Data Centre's perspective, one of the attempts did result in data being successfully
saved in the Data Centre but, due to the connectivity issues, the branch did not receive a
confirmation from the Data Centre. The branch will therefore record this as a failure.
Moving on to the end of the day the following Cash Declarations were made:
A. At 16:31:27 a Declaration was made for £22,160.54 followed by a variance check which
indicated a discrepancy (loss) of £1,237.16.
B. At 16:32:46 a second cash Declaration was made for £23,460.54 followed by a variance check
which indicated a discrepancy (gain) of £64.84.
Looking forwards, the following variance check discrepancies were recorded:
Date Variance Check Discrepancy Loss or Gain
04/10/2012 I £62.84 Gain
05/10/2012 I £66.15 Gain
06/10/2012 I £76.98 Gain
08/10/2012 I £71.91 Gain
09/10/2012 I £69.05 Gain
10/10/2012 I £63.99 Loss
The Stock Unit was Balanced and rolled over from Balance Period 3 into Balance period 4 on 10”
October and the Discrepancy committed to the accounts. (There was also a £37.75 discrepancy Gain
‘on stamps at the same time.)
5. Explanation of Recovery
The fact that a Log On (and Recovery) occurred at point 6 above indicates that there must have been a
failure just before that point and the User would have been informed of a Forced Log Off. The fact that
Recovery reversed most of the last Session recorded prior to the recovery indicates that the following
sequence of events occurred. This is confirmed by the statistics described above at point c in section 4
above.
The user must have been aware that there was a problem in this circumstance. What they would have
observed was the following:
1. Having completed the Bill Payment and Cash Withdrawal, the User would have either selected
“Settle” or “Fast Cash”. If Settle was selected then they would again have selected either
“Cash” (and keyed in the amount) or selected Fast Cash.
2. This would have completed the Basket and attempted to save the basket to the Data Centre.
3. Following a failure of the first attempt, the system would automatically carry out a retry and
attempt to save the basket to the Data Centre again.
4. Following the failure of the second attempt, a message would have been displayed to the User
informing them that there was a failure to contact the Data Centre and did they wish to Retry
or Cancel.
Strictly Private and Confidential; Subject to Legal Privilege 9 of 26
POL00122393
POL00122393
9.
10.
11.
12.
There are some parts of the
The fact that there were 4 attempts to contact the Data Centre, indicates that the User must
have selected Retry and so the system would have made a 3" attempt to save the basket to
the Data Centre.
Following a failure of the third attempt, the system would automatically carry out a retry and
attempt to save the basket to the Data Centre yet again.
Following the failure of the fourth attempt, a message would have been displayed to the User
again informing them that there was a failure to contact the Data Centre and did they wish to
Retry or Cancel.
The fact that there were only 4 attempts to contact the Data Centre indicates that the user
must have selected Cancel this time. This would have resulted in a Forced Log Out. This
means:
a. Horizon would cancel those transactions that could be cancelled. In this case, the BT
ill and the Cash “change” could be cancelled because (1) those transactions do not
get processed until the basket completes and in this instance the basket had failed.
b. The cash withdrawal transaction for £80 could not be cancelled. Prior to the
disconnect, Horizon had already contacted the customer's bank to confirm that a cash
withdrawal could be made from the customer's account. The customer's bank had
therefore already registered the hdrawal from the customer's account and this
transaction could not be cancelled.
c. Horizon would then re-calculate the basket showing that the customer should have
£80. This is because the only remaining transaction would have been the irreversible
cash withdrawal for £80.
d. Horizon would then have printed out 3 copies of the Disconnected Session Receipt
which would indicate this (one for Customer, one for Branch records and one to attach
to the till to aid with recovery).
e. It would not have printed out the AP receipt for the BT Bill.
f. Horizon would then have logged out and disconnected.
The SPMR should then have made sure that, in accordance with the Disconnect Receipt, the
Customer had been given cash to the sum of £80. It is at this point that the SPMR failed to
follow the instructions from Horizon in that he did not ensure that the customer had received
£80.
The system would then display the Log On screen.
Again the User must have been aware of this as at 09:37:19 they Logged On again
As part of the Log On process, the system checks the identity of the last basket successfully
saved at the Data Centre (which appears to be 537803) and compares it with the identity of
the last Basket successfully processed by the counter (in this case 537802). As the last basket
saved in the Data Centre has a higher number than that considered to be the last successful
basket processed by the counter, the recovery process in the Data Centre would then repeat
the process that the counter carried out at step 8 above. This would have generated the
Recovery Basket stored at 09:37:44 as Session 537805 (ie. the reversal of both the BT Bill and
the cash "change" but a valid transaction for the Cash Withdrawal). A Recovery receipt would
have been printed reflecting these transactions.
What the Logs don’t support
jal statement that are not supported by the logs. Specifically:
Strictly Private and Confidential; Subject to Legal Privilege 10 of 26
POL00122393
POL00122393
“At approximately 10:32 a customer tried to pay his £76.09 BT phone bill with his LTSB card
but was not successful. The customer then withdrew £80.00 cash and used this to pay the
phone bill.”
There is no indication of any attempt to pay this by card. Closer examination of the Business
Rules show that it is not permissible to pay for a BT Phone Bill with a Credit Card. However the
LTSB card used for the Banking withdrawal was a Debit (and not a Credit) Card. It could be that
an attempt was made to settle with a different Credit Card and the system indicated that it
was not acceptable. There is no record of any attempt to use the LTSB card as a Payment card.
Also, when checking for a failed card transaction in an earlier basket (point 3 in section 4), the
value of the failed payment was £141 and not £76.09. Therefore this couldn’t be the failure
referred to.
It would appear that the only attempt to pay this BT Bill was with the withdrawn cash.
“The SPMR stamped the customer’s phone bill to evidence receipt of the cash, returning
change of £3.91.”. This may be what the SPMR did. However if so he was not following the
instructions provided by Horizon as outlined in section 5. It is recognised that the bill may well
have been stamped prior to the Disconnected Session Receipts being produced.
As explained in section 5, there were a number of indications that the transaction was not
successful, and so the Bill payment had not been recorded:
a. The fact that the SPMR was asked twice about Retrying after failed Data Centre
interactions
b. The fact that 3 copies of the Disconnected Session Receipt would have been printed
out on the counter printer
c. The fact that no AP receipt to confirm payment of the Bill was printed
d. The fact that the User had to Log On again and a Recovery Receipt was printed.
“The SPMR did not initiate those reversals nor did he receive any reversal notifications.” The
SPMR did not initiate the reversals but he would have been notified. When Recovery was
carried out (point 7 in section 4) a Receipt would have been printed. Also messages are
displayed to the User during the recovery process.
“The SPMR raised this as an issue with Chesterfield but was told that due to cost issues Horizon
transaction data could not be requested. It was implied that the SPMR had stolen the money
and he was told to make good the shortage.” This is addressed in section 7 below.
“This meant that 2 people had paid the phone bill (the customer, who handed cash to the
SPMR and the SPMR on instructions from Chesterfield).” The logs show that if the customer
has paid the bill, this payment was not recorded on Horizon. This means that the phone bill
had not been paid as intended at the time of transaction. If in fact the SPMR had received the
payment and not recorded it on Horizon, then there should be a corresponding surplus of cash
at the branch.
It was to instigate the bill payment that FSC raised the Transaction Correction.
“The SPMR was informed that he should have a surplus of £76.09 due to the reversal of the
transactions.”. The figures in section 4 relating to cash declaration indicate that there was a
surplus of around £63 that day.
“The SPMR disputes this conclusion, but the more important issue here is the automated,
unreported, reversal of the transactions.”. The Automated Reversal is explained in section 5.
That section also explains that the SPMR should have been aware of this for a number of
reasons.
Strictly Private and Confidential; Subject to Legal Privilege 11 of 26
POL00122393
POL00122393
7 FSC’s Input
“The decision by P&BA not to examine the Horizon detailed transaction data on cost grounds
delayed or denied the SPMR the opportunity to process the transactions correctly or understand
what happened.”
It is noted that this is not an issue with Horizon but rather a question around Post Office Ltd's
processes for investigating disputes raised by SPMRs.
Horizon does retain full transaction logs. There is no question of this information not being
available or being somehow inaccurate.
These logs are not however readily accessible by Post Office and must requested from Fujitsu
at a cost. Post Office therefore only accesses the logs when it is proportionate to do so and
when an issue cannot be resolved using other available information.
In the case raised in this Spot Review, there was no need to access the transaction logs. First,
it was possible to determine what had happened in the branch from the "disconnect" and
recovery" receipts alone.
Secondly, the transaction logs would not have assisted the SPMR. The transaction logs would
only show the reversal of a transaction, not the method or reasons for that reversal. The logs
would therefore not show that the reversals were automatic responses to a disconnect
scenario.
Thirdly, to extract any meaningful information from the Horizon records requires the “raw’
transaction data to be interrogated. This cannot be done without technical expertise.
Fourthly, the above analysis proves that Post Office's assessment, based on the information
available at the time, was correct and its approach justified.
Strictly Private and Confidential; Subject to Legal Privilege 12 of 26
POL00122393
POL00122393
HORIZON — SPOT REVIEW 11
Reference Number: SRO11 Issue GIRO Payments - Date: Not date-specific
Type: Apparent Loss of Audit (this is a general
Trail point)
SPMR Name: Tracey Ann PO Yetminster and Chetnole I FAD: 267518
MERRITT. Branch:
Loss to the SPMR? YES noO Current Awaiting response from Category: I 1020
Status: POL
304
What the SPMR says happened
SPMRs cannot properly account for GIRO payments that have been made in their branch. The absence of printed
Receipts (that could be retained by SPMRs for future reference and investigative purposes) means that it is difficult to
investigate prior transactions. Consequently, incoming TCs from POL cannot be matched to previous GIRO transactions
and the SPMR simply has to “trust POL and accept the Transaction Correction”. Previously ‘slips’, relating to every day’s
transactions, were held in branch and could be used to investigate subsequent queries. Whilst Horizon always prints out
a Receipt for the customer, it never prints out one for the counter clerk. Horizon now only shows the SPMR an
AGGREGATE of ALL of that day’s GIRO transactions and the total that day’s Customer Card Withdrawals. Furthermore, it
is no longer possible to print a Transaction Log relating to any day prior to 42 days before the date of the Transaction
Log Request. This means that when an SPMR receives a TC more than 42 days after the transaction to which the TC
refers, the SPMR cannot investigate the matter and cannot mitigate any loss charged to them. It would appear that a
significant number of TCs are sent out more than 42 days after the underlying transaction(s). SPMRs are questioning
whether it is reasonable that POL holds them accountable for entries in their branch’s books which they are unable to
check and yet are expected to be accountable for.
Investigative work done
© POLis requested to provide statistical information about the number of days taken to send TCs to the SPMRs in
the Horizon Investigation Sample
* POLis requested to comment on the inability of SPMRs to disaggregate figures for which they are held
accountable.
POL Response
CONCLUSIONS
Strictly Private and Confidential; Subject to Legal Privilege 13 of 26
POL00122393
POL00122393
Horizon Spot Review - Response
SRO11: Giro Payments — Apparent Loss of Audit Trail
Executive Summary
It is noted that this Spot Review does not raise any suggestion that there is an error in Horizon. Rather, it is
focussed on Post Office procedures and branch processes.
There is no loss of audit trail for Giros because:
1. Branches are able to review on Horizon all transactions (including the deposit or withdrawal of Giros)
in the last 60 days; and
2. Branches are able (and indeed required) to print and retain a Daily Giro Report showing all Giro
deposits and withdrawals on a given day.
Transaction corrections are in the vast majority of cases supported with either evidence or a description of the
error in question. This allows branches to investigate any Giro transactions against the records retained in
branch.
Post Office Ltd is confident that adequate information is available to Sub-postmasters (SPMRs) for them to
review Giro transactions.
Spot review scope
Second Sight has been provided with Horizon Transaction Data from 1 March 2007 to 31 January 2012
recorded by Yetminster 267518. From the Spot Review, the following key issues have been identified:
1. SPMRs do not have access to records of individual Giro transactions to investigate subsequent
transaction corrections.
2. Horizon does not print off branch receipts ("slips") for Giro transactions.
3. SPMRs cannot properly investigate transaction corrections in relation to Giros.
General background
"Giros" refers to a method of making deposits and withdrawals from a banking system operated by Girobank.
This is distinct from Green Giros which are used for benefit payments. Green Giros are not considered in this
response.
Reference to Horizon means Horizon Online unless stated otherwise.
The key steps in the process for transacting a Giro deposit or withdrawal is as follows:
1. Customer presents a Giro at the counter.
2. SPMR enters the transactions details in to Horizon (deposit / withdrawal / amount / etc.)
Strictly Private and Confidential; Subject to Legal Privilege 14 of 26
POL00122393
POL00122393
3. Horizon produces a transaction receipt for the customer.
4. Atthe end of each day, the SPMR prints a Giro remittance slip from Horizon that shows details of each
Giro transaction that day.
5. The SPMR places the Giros and the Giro remittance slip in a pouch and sends this to the Post Office
[cash centre?].
6. After printing the Giro remittance slip, Horizon automatically prints a Giro Daily Report. This report
shows details of all Giro transactions that day.
7. The (CSunters manual?) requires that SPMRs keep a hardcopy of the Giro Daily Report for their own
records. [PLEASE PROVIDE A COPY OF THIS SECTION OF THE MANUAL?)
Issue 1: SPMRs do not have access to records of individual Giro transactions to investigate
subsequent transaction corrections.
This is incorrect. SPMRs have access to the following records:
1. Horizon retains details of all transactions (including Giros) in the last 60 days. SPMRs are free to
interrogate this information as required. (Note: the old Horizon system only retained records for 42
days which is the source of the reference to 42 days in the Spot Review).
2. After this 60 day period, SPMIRs can use the Giro Daily Report to investigate historic Giro transactions.
These reports will present a complete transaction history for Giros if the SPMR has properly followed
the correct procedure (as described above).
3. SPMRs can also choose to print a "stock unit" report each day which will show the total number and
value of Giros transacted each day. This report does not present a line by line breakdown but can be
used to ensure that other reports (such as the Giro Daily Report) have been properly produced,
remitted and retained in branch.
Issue 2: Horizon does not print off branch receipts ("slips") for Giro transactions.
This statement is correct. Horizon only prints a receipt for the customer. It does not print a receipt for the
SPMR to retain (commonly known as a branch receipt). The printing of branch receipts is unnecessary given
the other information available to SPMR — see Issue 1 above.
The Spot Review suggests that historically Horizon did print branch receipts for Giros. For the sake of clarity, no
version of Horizon has ever printed branch receipts for Giro transactions.
Issue 3: SPMRs cannot properly investigate transaction corrections in relation to Giros
Transaction corrections are issued to branches where there has been an error in the processing of Giros. The
key steps in the process for issuing a transaction correction for a Giro are as follows:
1. Anerror is identified. Typically this is because the number or content of the Giros recorded on Horizon
by the SPMR as being remitted to the [cash centre] is different to the number or content of the Giros
Strictly Private and Confidential; Subject to Legal Privilege 15 of 26
POL00122393
POL00122393
received by the cash centre. Sometimes, the error is generated by a discrepenacy between Girobank's
records and the Horizon record as input by the SPMR. There are however many other possible causes
of an error.
2. Post Office investigates the error. This may involve informally contacting the SPMR at an early stage
before a transaction correction is issued.
3. If the investigation concludes that the error was caused in branch, a transaction correction is issued to
the branch.
4. The time taken to issue a transaction correction varies depending on a number of factors including the
nature of the error and the response of Girobank and the SPMR to Post Office's investigations.
Further, some errors are only discoverable by customers who may take weeks/months to identify the
error before contacting Girobank / Post Office. Post Office tries to investigate all alleged errors itself
before engaging SPMRs so not to waste SPMRs' time on issues that can often be resolved without their
involvement.
5. In the vast majority of cases the transaction correction will be supported by either (1) documentary
evidence or (2) a commentary explaining the error on the face of the transaction correction. Post
Office endeavours to provide a clear picture of the error to the SPMR with every transaction
correction. However, given the significant volume of transaction corrections processed everyday, it is
accepted that a very small number may not contain complete information.
6. The SPM can contact Post Office at any time to request more information about the transaction
correction.
7. The SPM has a choice of whether to accept or dispute a transaction correction. The dispute process is
described in the "Horizon online help" at page btsb31.
Given the above process and the information available to SPMRs described in Issue 1, it is possible for SPMRs
to properly investigate any transaction correction regarding a Giro.
It is noted that various other in-branch processes may also reveal an error before a transaction correction is
issued (such as end of day processes and end of trading period processes).
Automated Payments
In an e-mail chain headed “SRO11 - Two Clarifications Required” and dated 6 March 2013 it was indicated that
this spot review may also extend to Automated Payments. To the extent applicable, the above processes are
similar to those for Automated Payments.
Strictly Private and Confidential; Subject to Legal Privilege 16 of 26
POL00122393
POL00122393
HORIZON — SPOT REVIEW 12
Reference Number: I SRO12 Issue Missing cheques Date: 12/08/2004 -
Type: 07/04/2006
SPMR Name: Jo HAMILTON PO South Warnborough FAD: 092904
Branch:
Loss to the SPMR? yes X no O Current Awaiting response from Category: I 1020
Status: POL
304
What the SPMR says happened
Part of the shortfall charged to the SPMR by POL, and cited by POL in court when the SPMR was charged with False
Accounting, was attributable to missing cheques that the SPMR had sent to Chesterfield for processing. Several cheques
presented to the SPMR by customers have never cleared through the customers’ bank accounts. One of the SPMR’s
regular customers has provided a list of cheques that are evidence of this. It has not been possible to re-build the entire
audit trail of what happened and match this to Transaction Corrections (‘TCs’). The SPMR also reports that she once
found pouches (known as ‘Stripeys’) containing customer cheques in the street outside her Branch, these seemingly
having been accidentally dropped by the Royal Mail collector.
TCs typically came out 3 months or more after the processing date, making it virtually impossible for the SPMR to
recover funds from the customer. The SPMR did not raise this matter at trial, since the significance of this matter was
not identified until after the trial concluded.
The SPMR also reported an article in The Sunday Times’ ‘Question of Money’ column on January 28", 2007 describing a
near-identical situation concerning the purchase of £2,500-worth of Premium Bonds using a cheque that never cleared.
The Sunday Times reported that POL said that “the cheque could have been ‘mutilated’ in the clearing process”. The
article also stated that after numerous attempts to get anyone to take the matter seriously the SPMR was told by a POL
employee, "not to worry about it, just take a holiday with the money.”
Investigative work done
Loss of cheques, whether in the branch, in the delivery chain or in POL’s Processing Centre, could well result in a real
financial loss to an SPMR. However, such an event should not give rise to a mysterious or unexplainable shortage. The
Post Office’s standard procedures are designed to identify the non-receipt of cheques sent to Chesterfield for
processing. Non-receipt of cheques would normally give rise to a TC, as would a cheque returned unpaid by the
customer’s bank. Unfortunately, due to the length of time that has elapsed in this case, neither the SPMR nor POL has
relevant records to establish whether the SPMR was notified of non-receipt in a proper and timely manner.
SPMRs typically have no record of cheques that are received from customers and sent to the Processing Centre.
Consequently, indentifying the relevant customer is far from straightforward. If the SPMR is not able to match
customers who have presented cheques to the relevant TC, then they will be unable to effect recovery. POL would
however, be entitled to recover the missing funds from the SPMR under the standard contract.
Strictly Private and Confidential; Subject to Legal Privilege 17 of 26
POL00122393
POL00122393
* POLis invited to comment on the apparent inequity of POL mitigating losses arising from lost cheques by
making recoveries from the SPMR whilst denying the SPMR the opportunity to make recoveries from
customers, due to POL not sending out TCs in a timely manner.
POL Response
CONCLUSIONS
Strictly Private and Confidential; Subject to Legal Privilege
18 of 26
POL00122393
POL00122393
Horizon Spot Review - Response
SR012: Mi ig Cheques
Executive Summary
It is noted that this Spot Review does not raise any suggestion that there is an error in Horizon. Rather, it is
focussed on Post Office procedures and branch processes.
It is acknowledged that a cheque loss could occur at the branch, in the Royal Mail pipeline or at the FSC. Post
Office's policy is that a branch will only bear the cost of a lost cheque if the SPMR has failed to follow proper
operation processes and POL has been unable to mitigate the loss by other means. If the root cause of a lost
cheque is unknown or attributed to some other cause outside the branch, POL will absorb this loss and not
pass it on to the SPMR.
Only around 2% of missing cheque cases results in transaction corrections being issued to a branch.
Spot review scope
From the Spot Review, the following key issues have been identified:
1. There are "mysterious" or "unexplained" shortages in the remittance of cheques from branch to POL
which lead to transaction corrections being issued against SPMRs.
2. By the time a transaction correction is raised in relation to a missing cheque, it has become impossible
for the SPMR to identify the customer who handed over the cheque. The SPMR cannot therefore
mitigate the loss and this is inequitable.
3. Various other matters specific to the case of Ms Jo Hamilton.
General Background
Branch process
Most Post Office branches are entitled to accept cheques from customers as the method of payment for a
range of designated counter transactions. The cheque should be scrutinised and the reverse of the cheque
needs to be date stamped, initialled and relevant transaction details recorded on the reverse. This will enable
identification of the relevant product and customer.
The method of payment should be recorded as a part of the Horizon transaction. The cheque is then recorded
on Horizon as a part of the branch stock held. There are no customer details recorded on Horizon or retained
in branch.
All cheques taken should then be despatched from the branch via the final Royal Mail collection of the day
(except Fridays). The branch process for remitting cheques is as follows:
1. SPMR produces a cheque listing report from Horizon.
Strictly Private and Confidential; Subject to Legal Privilege 19 of 26
POL00122393
POL00122393
2. SPMR verifies that the cheques held in the till match (volume and value) against the cheque listing
report.
3. The total cheque value is then marked on Horizon as being remitted to POL (known as "remmed out").
4. A further cheque listing report is then produced. This will show the cheques being remmed out as a
negative value. The report total will now total zero.
5. The cheque listing report is cut off. The branch cheque stock will now also be zero.
6. A Batch Control Voucher (BCV) is then manually completed to show number of cheques, value and
despatching branch. The cheques are attached to the BCV. The cheques are then despatched for
processing in the relevant envelope via Royal Mail to the Financial Service Centre (FSC) - not
Chesterfield as incorrectly stated in the Spot Review.
7. Horizon cheque listings and remittance slips are retained in branch.
FSC process
The POLSAP finance system at the FSC is automatically uploaded each night via the Horizon-POLSAP Finance
Interface. The cheque team in FSC are able to view this data the day after the transactions and will see the
outward remittances recorded (day 1). All Horizon transactional data is “polled” into FSC ledgers at summary
level via this process.
On day 2 an electronic file will be received from the cheque processor via an automatic upload into POLSAP to
represent the actual cheques received from each branch.
The cheques sent by the branches are then compared and cleared by FSC against the POLSAP records where
they match each cheque against its "remitted" value.
Approximately 1,000 entries will remain unmatched each day (ie. there is a discrepancy between the cheques
received by FSC and the information sent via Horizon by SMPRs about cheque remittances) and could be an
indication of missing cheques. Many cases are resolved quickly (ie. late delivery by Royal Mail or the SPMR
missed the collection). There will be around 100 cases per month where it becomes apparent that a cheque
has actually gone missing.
Investigating lost cheques
It is acknowledged that a cheque loss could occur at the branch, in the Royal Mail pipeline or at the FSC. Post
Office's policy is that a branch will only bear the cost of a lost cheque if the branch has not followed proper
procedures. If the root cause of a lost cheque is unknown or attributed to some other cause outside the
branch, POL will absorb this loss and not pass it on to the SPMR. In around 98% of cases Post Office either
mitigates the loss caused by a lost cheque or absorbs the loss itself. Only approximately 2% (TOBE
CONFIRMED} of missing cheque cases result in transaction corrections being issued to a branch.
The process for investigating missing cheques is as follows:
«The transaction to which a missing cheque relates is identified from the information input into Horizon
by the SPMR.
«Branches will be contacted when the missing cheque case is set up to see if the cheque can be found in
branch or if they are aware of which customer has presented the cheque which has subsequently gone
missing.
Strictly Private and Confidential; Subject to Legal Privilege 20 of 26
POL00122393
POL00122393
e If the branch cannot find the lost cheque, a variety of techniques (depending on product/information
available) is employed to identify the customer and their address from the transaction data.
* The customer is then contacted to request a replacement cheque. If a replacement cheque is provided
then the loss to Post Office is avoided.
* Ifareplacement cheque is not forthcoming, the relevant client organisation (ie. the product supplier,
say Bank of Ireland, Environment Agency, etc.) is informed that the payment for that particular
transaction has not been received and the transaction is reversed where possible. By reversing the
transaction, the loss to Post Office is avoided.
* Alternatively, if Post Office is unable to identify the customer details, the relevant client organisation
may be is asked to try to contact the customer directly for payment. By payment being made direct
from the customer to the client, the loss to Post Office is avoided.
If payment cannot be recovered from the customer or the client and the transaction cannot be
reversed, Post Office will absorb the loss of the cheque provided operational instructions have been
followed at the branch.
«There are 2 typical scenarios where an SPMR has failed to follow operational processes and will be
held liable for missing cheques:
1. Cheques have been accepted by the SPMR for a non-cheque acceptable product (e.g. Bureau
sales). By accepting payment by cheque for a non-cheque acceptable product, it may not be
possible to link a missing cheque to a transaction record. If the transaction record cannot be
identified then it may not be possible to identify the customer and/or client. This then frustrates
Post Office's usual loss mitigation steps described above.
2. The method of payment has not been correctly recorded on Horizon with cheques as the method
of payment and it subsequently proves impossible to associate any transactions with the cheques.
Such an instance will typically be illustrated by branches recording multiple/all transactions
through “Fast Cash” and then introducing a bulk cheque value to Horizon via a “Cash/Cheque
Adjustment” at the end of the day prior to remitting out.
Issue 1: There are "mysterious" or "unexplained" shortages in the remittance of cheques from
branch to the POL which lead to transaction corrections being issued against SPMRs.
As explained above, where the root cause of a missing cheque cannot be identified, Post Office absorbs the
loss itself and does not pass the loss on to SPMRs. Loss caused by missing cheques is only passed on to SPMRs
by way of a transaction correction if the SPMR has not followed the set operational processes for taking and
recording cheque transactions.
Issue 2: By the time a transaction correction is raised in relation to a missing cheque, it has become
impossible for the SPMR to identify the customer who handed over the cheque. The SPMR cannot
therefore mitigate the loss and this is inequitable.
Strictly Private and Confidential; Subject to Legal Privilege 21 of 26
POL00122393
POL00122393
As explained above, a transaction correction is only issued to a SPMR where the SPMR has failed to follow
proper operation processes and POL has been unable to identify a customer by other means. In this scenario,
it is fair and equitable that the loss should be passed back to the SPMR.
It is recognised that once a transaction correction is issued, a SPMR may not be able to identify the relevant
customer in order to obtain a replacement cheque. Post Office tries to investigate all missing cheques itself
before issuing a transaction correction so not to waste SPMRs' time on issues that can often be resolved
without their involvement. It is noted however that the transaction correction date is largely irrelevant as an
enquiry will, in most cases, have already been raised with the branch about a missing cheque.
Even if there was a significant delay in notifying an SPMR of a missing cheque, providing additional Horizon
data or transaction records will not provide branches with the information to identify a customer as it will be
an error in the Horizon data that has caused the cheque to go "missing" in the first instance.
If SPMRs follow operational instructions when processing cheques, they will not be held liable should if chques
subsequently go astray. The prime requirements are for branches to only accept cheques as a method of
payment on cheque acceptable products and to record transactions accurately with cheque as the method of
payment on Horizon. By following the set operational processes, SPMRs can avoid any liability for missing
cheques.
ic to the case of Ms Jo Hamilton
Issue 3: Various other matters spe
Horizon data is held for 7 years. This means that no transactional information is available to investigate this
specific case.
It is also impossible to comment on what an unnamed Post Office employee is alleged to have said back in
2007 as reported in the Sunday Times. In any event, it is impossible for a SPMR to just "take the money"
generated by a missing cheque as, by its very nature, a missing cheque does generate extractable cash. Post
Office can only assume that the SPMR has wholly misunderstood the processes around cheque remittances.
Strictly Private and Confidential; Subject to Legal Privilege 22 of 26
POL00122393
POL00122393
HORIZON — SPOT REVIEW 13
Reference Number: I SRO13 Issue Missing cheques Date: 23/05/2005 —
Type: 15/08/2005
SPMR Name: Jo HAMILTON PO South Warnborough FAD: 092904
Branch:
Loss to the SPMR? yes X no O Current Awaiting response from Category: I 1020
Status: POL
304
What the SPMR says happened
ATC was issued to her branch in respect of a TV Licence paid for by one of her regular customers. The customer had
presented a cheque in the sum for £126.50 on 23rd May 2005. This cheque was sent in a pouch along with four other
cheques to Chesterfield for processing. On 15th August 2005, a TC was issued to her branch by POL. The TC said that:
“Following an enquiry from TV Licensing at Bristol a licence was issued to Mr XXXXX (name was supplied) on 23 May
2005 in Week 09 but not entered onto Horizon. Therefore £126.50 to be charged”.
The customer received his TV Licence and the cheque did clear and was debited to his bank account (a copy of the
cheque is on file).
The reason for the TC is not clear, as correct payment for the TV licence appears to have been made. The SPMR was
unable to reclaim the money i.r.o. the TC and has suffered a loss which was not caused by her error.
See attached documents
Investigative work done
© POLis requested to comment on the matter reported by the SPMR
POL Response
CONCLUSIONS
Strictly Private and Confidential; Subject to Legal Privilege 23 of 26
POL00122393
POL00122393
Strictly Private and Confidential; Subject to Legal Privilege 24 of 26
POL00122393
POL00122393
Horizon Spot Review - Response
SRO1:! issing Cheques
Executive Summary
Due to the age of the transaction in question in this Spot Review (2005), the transaction history is no longer
available and a detailed investigation cannot be conducted.
Nevertheless, it is thought (though this cannot be proven conclusively) that this case does not relate to missing
cheques but rather to a TV licence transaction correction. In Post Office's experience this type of situation
arises where a SPMR fails to properly record a TV licence transaction on Horizon.
In any event, it is noted that this Spot Review does not appear to raise any suggestion that there is an error in
Horizon. Rather, it is focussed on Post Office procedures and branch processes in one specific case.
Detailed Response
Below is one possible explanation of what may have happened in this case. However, as this transaction took
place in 2005 there are no longer any records available to fully investigate this matter.
1. In 2005, TV licences could be renewed at Post Office branches.
2. It is thought that the customer presented his/her TV licence renewal at the branch. The SPM then
accepted a cheque in payment, stamped the TC licence as having been renewed but did not process
the transaction through Horizon. The stamp on the licence is unique to that branch and shows the
date of the transaction.
3. As the transaction was not recorded on Horizon, the TV licencing authority will therefore not have
received a notification via Horizon that the customer’s licence had been renewed.
4. Further, the customer's cheque will initially not have formed part of the branch stock as Horizon would
have no transaction on record.
5. As the cheque (for £126.50) was ultimately remitted out of Horizon and despatched for processing it
must have been introduced manually by the SPMR onto Horizon. This will most probably have been
done through a cash/cheque adjustment.
6. The impact of this adjustment will have been to increase the cheque stock by £126.50.
Simultaneously, Horizon will have automatically reduced the “derived” cash position by £126.50.
Assuming the branch was in balance at this point, the adjustment would have generated a "actual"
cash surplus of £126.50.
7. Atsome later date, the TV licencing authority will have approached the customer about his/her
expired TV licence who presumably then produced the stamped TV licence as evidence of payment.
8. The TV licencing authority will then have raised an error with Post Office Ltd requesting settlement for
the transaction.
Strictly Private and Confidential; Subject to Legal Privilege 25 of 26
POL00122393
POL00122393
9. Post Office will have interrogated branch records but no licence payment will have been found for the
date in question. As Post Office cannot defend the error, it will therefore have paid the TV licencing
authority.
10. A transaction correction (or in 2005 this would have actually been an Error Notice) will then have been
issued to the SPMR in respect of this payment.
11. This transaction correction would then net off against the cash surplus described above. This means
there was no financial loss to the branch.
Strictly Private and Confidential; Subject to Legal Privilege 26 of 26