POL00337673
POL00337673
Historic KELS
Determination and
Closure
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
Table of Contents
1 Introduction...
Change log
Authorisation log
Summary of the Historical KELS
Historical KELs.....
Oak wN
Appendix ...
STRICTLY CONFIDENTIAL [Publish Date] 1
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
1 Introduction
The following report is a summary of the determinations of the historical known error logs (KELS). These KELS were
identified during the Post Office Horizon IT Inquiry as having potential Postmaster detriment. Each historical KEL was
investigated, and analysis was performed by the Post Office and Fujitsu to determine if the historical KEL needed
retesting. This document forms part of the signoff, along with the Closure Test Report from Fujitsu and POL, with the
expectation that it will approved by the Postmasters.
Please see section Appendix 5 - ‘POL_Test Closure Report - Historical KELS v0.6’ and ‘TSTOTREP4269.DOCX’ in
conjunction with this document.
To ensure confidence where retesting was required for a KEL, the retesting was performed diligently step by step,
using the POL and Fujitsu standard testing methodology, capturing the appropriate evidence, to validate that the KEL
does not exist in the current Horizon platform.
STRICTLY CONFIDENTIAL [Publish Date] 2
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
2 Change log
POL00337673
POL00337673
©
Date Issued Version Description of Change Author
16/06/21 v0.2 Initial draft Kayzy Thandi
18/06/21 v0.3 Comments by BDR Kayzy Thandi
23/06/21 v0.4 Incorporated comments by BDR and changes to format Kayzy Thandi
28/06/21 v0.5 Changed version to v0.5 Kayzy Thandi
STRICTLY CONFIDENTIAL
[Publish Date]
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2021
3 Authorisation log
Project Name: Historical KELS Project Manager: Harshwardhan Soman
Start Date: 10" May 2021 (Completion Date: 25" May 2021
Name: Simon Oldnall Name: Harshwardhan Soman IName: Sree Balachandran
[Role: POL Horizon IT Director Role: POL Head of QA Role: POL Head of Postmaster
Experience
IBy signing this document, I By signing this document, I By signing this document, I
jacknowledge that I have delivered jacknowledge that I have jacknowledge that I have delivered all
jall the stated deliverables at the delivered all the stated the stated deliverables at the agreed to
jagreed to quality levels. \deliverables at the agreed to quality levels.
quality levels.
Signature: Signature: Signature:
[Date: Date: Date:
STRICTLY CONFIDENTIAL [Publish Date] 4
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2021
4 Summary of the Historical KELS
1 01 Receipts and Payments mismatch bug Ready for Signoff
2 02 Callendar Square/Falkirk bug Ready for Signoff
3 03 Suspense Account bug Ready for Signoff
4 04 Dalmellington bug/Branch Outreach Issue Ready for Signoff
5 5.1 Remming In bug — Issue 1 Ready for Signoff
6 5.2 Remming In bug — Issue 2 Ready for Signoff
7 6.1 Remming Out bug — Issue 1 Ready for Signoff
8 6.2 Remming Out bug — Issue 2 Ready for Signoff
9 07 Local Suspense Account issue Ready for Signoff
10 8.1 Recovery Issues — Issue 1 Ready for Signoff
iL 8.2 Recovery Issues — Issue 2 Ready for Signoff
12 09 Reversals Ready for Signoff
13 10.1 Data Tree Build Failure discrepancies — Issue 1 Ready for Signoff
14 10.2 (i) Data Tree Build Failure discrepancies — Issue 2(i) Ready for Signoff
15 10.2 (ii) Data Tree Build Failure discrepancies — Issue 2(ii) Ready for Signoff
16 11.1 Girobank discrepancies — Issue 1 Ready for Signoff
17 11.2 Girobank discrepancies — Issue 2 Ready for Signoff
18 11.3 Girobank discrepancies — Issue 3 Ready for Signoff
19 11.4 Girobank discrepancies — Issue 4 Ready for Signoff
20 11.5 Girobank discrepancies — Issue 5 Ready for Signoff
21 11.6 Girobank discrepancies — Issue 6 Ready for Signoff
22 12.1 Counter-replacement issues — issue 1 Ready for Signoff
23 12.2 Counter-replacement issues — issue 2 Ready for Signoff
24 12.3 Counter-replacement issues — issue 3 Ready for Signoff
25 13 Withdrawn stock discrepancies Ready for Signoff
26 14.1 Bureau discrepancies — Issue 1 Ready for Signoff
27 14.2 Bureau discrepancies — Issue 2 Ready for Signoff
23 15.1 Phantom Transactions — Issue 1 Ready for Signoff
29 15.2 Phantom Transactions — Issue 2 Ready for Signoff
30 15.3 Phantom Transactions —Issue 3 Ready for Signoff
31 16.1 Reconciliation issues — Issue 1 Ready for Signoff
32, 16.2 Reconciliation issues — Issue 2 Ready for Signoff
33 16.3 Reconciliation issues — Issue 3 Ready for Signoff
34 16.4 Reconciliation issues — Issue 4 Ready for Signoff
35 16.5 Reconciliation issues — Issue 5 Ready for Signoff
36 16.6 Reconciliation issues — Issue 6 Ready for Signoff
37 17 Branch Customer discrepancies Ready for Signoff
38 18.1 Concurrent logins — Issue 1 Ready for Signoff
39 18.2 Concurrent logins — Issue 2 Ready for Signoff
40 19 Post & Go/TA discrepancies in POLSAP Ready for Signoff
41 20.1 Recovery Failures — Issue 1 Ready for Signoff
42 20.2 Recovery Failures — Issue 2 Ready for Signoff
43 20.3 Recovery Failures — Issue 3 Ready for Signoff
44 21.1 Transaction Correction Issues — Issue 1 Ready for Signoff
45 21.2 Transaction Correction Issues — Issue 2 Ready for Signoff
46 21.3 Transaction Correction Issues — Issue 3 Ready for Signoff
22.1 Bugs/errors/defects introduced by previously applied Peak fixes Ready for Signoff
47 " =Issue 1
333 Bugs/errors/defects introduced by previously applied Peak fixes I Ready for Signoff
48 — Issue 2
23 Bugs/errors/defects introduced by previously applied Peak fixes I Ready for Signoff
49 —Issue 3
50 23.1 Bureau de change — Issue 1 Ready for Signoff
STRICTLY CONFIDENTIAL [Publish Date] 5
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
51 23.2 Bureau de change — Issue 2 Ready for Signoff
52 23.3 Bureau de change — Issue 3 Ready for Signoff
53 24 Wrong branch customer change displayed Ready for Signoff
54 25 Lyca Top Up Ready for Signoff
55 26.1 TPSC 250 Report — Issue 1 Ready for Signoff
56 26.2 TPSC 250 Report — Issue 2 Ready for Signoff
57 26.3 TPSC 250 Report — Issue 3 Ready for Signoff
58 26.4 TPSC 250 Report — Issue 4 Ready for Signoff
59 26.5 TPSC 250 Report — Issue 5 Ready for Signoff
60 27 TPS Ready for Signoff
61 28 Drop & Go Ready for Signoff
62 29.1 Network Banking — Issue 1 Ready for Signoff
63 29.2 Network Banking — Issue 2 Ready for Signoff
STRICTLY CONFIDENTIAL [Publish Date] 6
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5 Historical KELs
The sixty-three historical KELs are detailed in the following pages, outlining the system affected by the issue, when
the issue was discovered, what were the events around the issue, the technical underlying cause of the issue, and if
testing is required. For any testing commentary, please refer to the embedded test completion reports in the Appendix
of this document.
5.1 01 Receipts and Payments Mismatch Bug
Item I Component Commentary
Horizon System Horizon Online
5.11. I affected
The bug causes a problem with balancing, resulting in a mismatch between Payments and
5.1.2 I Description Receipts which meant that they did not match correctly when moving discrepancies into Local
Suspense, which resulted in discrepancies becoming “lost”.
5.1.3 I Dates 2010
Branches must rollover into a new Trading Period (TP) every month and may not rollover with an
unresolved discrepancy. If discrepancies were found when rolling a stock unit (SU), Horizon
prompted the user to decide to either:
a) Move the discrepancies into the Suspense Account (which aggregated all discrepancies
into a single gain or loss for a TP, and which then allowed rollover to complete), or,
b) Cancel the rollover.
The bug however allowed Postmasters to rollover with an unresolved discrepancy. The problem
only arose in a branch where all the following conditions were true:
5.1.4 I What Happened © The branch had an unresolved discrepancy, and,
* The branch cancelled (as in option b above) the completion of the TP; i.e. did not
transfer the discrepancy to the Suspense Account (option a above), and,
* Within the same session the branch then continued to rollover to a new Balance or TP.
A bug in the code meant that when Cancel was pressed (option b) the discrepancy was cleared,
and as it was not moved into the Suspense Account, an accounting error occurred. If the user did
not check the Final Balance Report then they may not have been aware that there was now a
receipts and payments mismatch, although the discrepancy would re-appear and be recorded on
the next TP.
The functionality of Rollover has changed since this KEL occurred, and the current codebase no
longer acts in the same manner. Additionally, the Suspense functionality is no longer performed
5.1.5 Tecnica in the same manner either, or how this activity now occurs has also changed.
ste nalysis
This functionality can be tested - a Rollover can be performed in the test environment, and it can
be checked if the Cancel button functions correctly.
oe Branch Trading Statement as part of Branch Balancing. The branch should be unable to roll over
5.1.6 I Required? without transferring the discrepancy to the suspense account. This Process is enforced by
Horizon and there is no mismatch between receipt and payments.
STRICTLY CONFIDENTIAL [Publish Date] 7
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.1.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 8
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.2 02 Callendar Square / Falkirk bug
Item I Component Commentary
Horizon
5.2.1. I System Legacy Horizon - Riposte
Affected
A software bug in Riposte could cause Horizon to no recognise transfers between different SUs so
that information recorded on the sending terminal was not passed to the receiving terminal. If the
Postmasters re-entered the transfer on a different terminal, then the transfer was registered twice
resulting in a discrepancy in the branch accounts.
5.2.2 I Description
5.2.3 I Dates 2000 to 2010
A bug in the Riposte software sometimes had the effect of preventing a counter from writing
messages, either those being replicated to it, or those generated on that counter.
1. When the Postmaster completed the ‘Transfer In’ on one counter, the confirmation
message indicating that this had been processed was not replicated to the other counters.
2. The problem was not always immediately obvious to the Postmasters/counter user and
could result in them attempting to re-enter the transfers which they believed they had
done but could see were missing.
3. Since the transfer had not been replicated, the Postmaster was then able to repeat the
same ‘Transfer In’.
4. When the counter was re-started, all repeat instances of the Transfer In would become
visible, which would cause errors in the accounts.
5. Attempting to balance the branch when a counter was in this state could also result in
errors.
What
5.2.4 I Happened
In the Callendar Square case, the issue was that the recording of the case being transferred into the
SU was not being made visible to other terminals, and so it was possible to repeat the Transfer In
on another terminal. The Riposte issue would mean that the terminal o which the first Transfer In
was recorded was no longer operable until it was restarted.
The root cause of this defect was a bug in the Riposte code. Riposte was counter code, which was
specific to Legacy Horizon, and how Horizon functioned prior to being replaced by Horizon Online.
This code has since been replaced. There is still some legacy code (in the form of “agents” - these
Technical are code components which are used for communication between the counter applications and the
5.2.5 I analysis databases) which remain, but this has been repurposed to communicate with the Branch Database
(BRDB). These agents are no longer the same as they were in Legacy Horizon.
This scenario can no longer be reproduced in Horizon Online, and the system no longer functions in
this manner.
Testing
Required? No testing can be performed for this scenario.
5.2.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 9
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.3 03 Suspense Account bug
Item I Component Commentary
Horizon System
Affected
53.1. Horizon Online.
Historic data from 2010 reappeared in some branches' accounts for the same monthly TP in 2011
5.3.2. I Description and 2012. Postmasters then re-settled those same entries to dear their Local Suspense accounts in
2011 and 2012 despite having settled them in 2010. Some branches benefitted from the same gain
three times or suffered from the same loss three times.
5.3.3 I Dates 2011 and 2013.
Although branch account data from 2010 was involved, the bug arose in 2011.
The issue was caused by a bug in the changes made to the archiving strategy relating to SUs on 3
July 2011. Some records associated with deleted SUs that should have been archived were ignored
by the archiving process, leading to those records becoming visible in the same monthly TPs in
2011 and 2012.
Asa result, some Postmasters re-settled incorrect entries to clear their Local Suspense accounts,
despite those entries already having been settled in 2010.
What 14 branches were identified as having old erroneous data in their accounts, which had an impact
5.3.4
Happened on Suspense Accounts.
19 additional branches were identified as having old data, although in these cases, the old data did
not affect the Suspense Accounts, and was unlikely to have an ongoing impact on branch accounts.
In affected Branch Trading Statements, it was found that the sum of the two 'Discrepancy
Transferred! lines did not match the total of the two ‘Discrepancy Resolved' lines.
In affected Suspense Account reports, it was found that the 'B/Fwd' figure on the report did not
match the 'C/Fwd' figure on the report from the previous TP.
Transactions should be injected into the Branch Database (BRDB) and deleted afterwards to
Technical ensure that if the transaction impacts the BTS or Suspense, the Postmaster is alerted. Note that
Analysis the functionality of Suspense has been changed from how it worked previously, when this item
was raised,
5.3.5
Testing Transactions to be injected and deleted into the Branch Database (BRDB) to ensure the BTS or
Required? Suspense Account is impacted in the correct way, this would be detected, and the Postmaster
would be alerted.
5.3.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 10
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2021
5.4 04 Dalmellington bug/Branch Outreach Issue
Item I Component Commentary
Horizon System .
5.4.1 I attected Horizon Online.
This affected core and outreach branches only. The bug allowed a Postmaster to inadvertently
Rem In cash to the outreach branch multiple times using the same barcode, so that a multiple of
the actual cash transfer would be recorded at the outreach branch, causing a discrepancy.
5.4.2 I Description
5.4.3 I Dates 2010 to 2016.
The effects of this bug arose only because of particular events, such as at Dalmellington:
1. The user logged into Horizon to make a cash declaration; following this the SU timed
out and logged off due to inactivity.
2. The user logged back in to the SU and carried out the remittance delivery transaction
(i.e. the
Rem out to the outreach branch). Two delivery slips were printed, the user pressed
Enter, which then printed the Rem In slip.
3. Instead of the Remittances and Transfers Home screen being displayed, the Pouch
5.4.4 I What Happened Delivery
Screen continued to display, with the Enter button enabled.
4. The user then pressed Enter three times, with the result that as well as the £8,000
originally Remmed out of the core branch, an additional £23,000 (3 x £8,000) was
Remmed out.
‘Asa result, the outreach branch showed a £23,000 discrepancy; the Dalmellington core branch
showed no discrepancy.
On investigation it was found that the ability to Rem in duplicate barcodes had existed since
Release 1 of HNG-X in 2010 and that other branches had been affected.
The user should not be able to rem out/ rem in with the same barcode twice. This should be
5.4.5 I Technical Analysis I prevented, and the user should either receive an error message, or the system should reject the
second attempt to Rem in with the same barcode.
5.46 I Testing Required? I The system should not allow to rem out/ rem the same barcode twice. A message should be
displayed. The office type would need to be configured as Outreach.
5.4.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 1
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.5 5.1 Remming In bug - Issue 1
Item I Component Commentary
Horizon System . .
5.5.1. I affected Horizon Online.
5.5.2. I Description When Remming in cash pouches, a Postmaster was able to Rem in the same pouch more than
once by scanning the same barcode.
5.5.3 I Dates 2010.
The system was designed to check if a barcode had already been scanned, and to reject it if it an
attempt was made to enter it again. However, the barcode would only be added to the Remmed
in list once the Rem process was fully complete.
In this instance, the Postmaster scanned a pouch on counter 1, but did not complete the Rem in
process before moving to counter 2, logging in with different credentials, and then scanning the
same barcode again.
The Rem in process completed on counter 2, but the Postmaster then returned to counter 1 and
5.5.4 I What Happened .
completed the incomplete Rem (of the same barcode) on counter 1. Because the barcode had
already been scanned but not cancelled on counter 1, it did not need to be scanned again, and it
was possible to complete the Rem in. Had the Postmaster cancelled and restarted the process
‘on counter 1, Horizon would have prevented this second Rem from the same barcode, as it
would already have been added to the list of scanned barcodes as a result of the completed
Rem on counter 2.
As a result, the same Rem in was recorded twice, causing two lots of the same cash to be added
to the branch accounts, creating a shortfall.
The user should not be able to rem in with the same barcode twice. This should be prevented,
5.5.5 I Technical Analysis I 254 the user should either receive an error message, or the system should reject the second
attempt to Rem in with the same barcode.
5.5.6 I Testing Required? I An error message should be displayed, or the system should reject the second attempt to Rem
in with the same barcode.
5.5.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 12
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2021
5.6 5.2 Remming In bug Issue 2
Item I Component Commentary
Horizon System . .
5.6.1. I attected Horizon Online
5.6.2. I Description When Remming in cash pouches, a Postmaster was able to Rem in the same pouch more than
once by scanning the same barcode.
5.6.3 I Dates 2010,
The Postmaster started Remming in a pouch by scanning its barcode, but then pressed "PREV"
which moved back one screen. The Postmaster then scanned the same barcode again. Horizon
Online only printed one receipt which would make it appear to the Postmaster that there had
been only one Rem in.
5.6.4 I WhatHappened I the duplicate Rem would have been recorded in the branch transaction records, resulting in a
shortfall.
It was also possible to return to the barcode scan screen by pressing "PREV" on the print screen
when attempting to reprint the receipt, and this would also present an opportunity for the same
barcode to be scanned again.
The user should not be able to rem in with the same barcode twice. This should be prevented,
5.6.5. I Technical Analysis I oq the user should either receive an error message) or the system should reject the second
attempt to Rem in with the same barcode.
5.6.6 I Testing Required? I An error message should be displayed/ or the system should reject the second attempt to Rem
in with the same barcode.
5.6.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 13
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.7 6.1 Remming Out bug Issue 1
Item I Component Commentary
Horizon System
ani. Affected Legacy Horizon.
On a Monday following a weekend counter release (T30 INC1) branches reported imbalances
5.7.2. I Description when Remming out cash or stock. The imbalances occurred when Remming out multiple
identical items separately, instead of Remming them out as a single batch using the quantity
button.
5.7.3 I Dates February 2007
Postmasters Rem out cash to be collected and returned to the POL cash centre. Each bag can
hold only one denomination (£1 coins, £5 notes etc.), and multiple bags are placed in a pouch.
The branch recorded in Horizon the amount in each pouch, by the number of bags, and the
value and the denomination in each bag. Once Remmed out, the cash was removed from the
branch cash holdings in Horizon but was recorded in a temporary "cash in pouches" line, where
it remained until the pouch was physically collected. The collection team scanned the pouch
barcode which removed it from the "cash in pouches" line in Horizon.
When a Postmaster had, for example, two bags of 500 x £2 coins, Horizon expected this data to
be entered in a single entry as 2.x 500 x £2 coins, with the quantity button used to indicate 2
5.7.4 I What Happened I pags. As a result of this bug it became apparent that many Postmaster would instead, in this
example, enter 1 x 500 x £2 coins, and then repeat the entry to record the second bag.
The bug led to only one of the two separately entered bags being recorded as leaving the
branch cash holdings, although both bags would be recorded on the "cash in pouches" line.
When both bags were collected, only one bag was recorded as removed from the branch cash
holdings, although two bags had been physically removed.
If the branch spotted the shortfall created in the branch cash holdings and tried to reverse the
Rem of one bag, then the branch cash holdings would be corrected, but the amount would
remain in the "cash in pouches" line within the Suspense Account, something which could not
be adjusted by the branch, and a TC would be required.
The user was unable to rem in with the same barcode twice. This should be prevented, and the
5.7.5 I Technical Analysis /HB\ uid offer receive an error message, or the system should reject the second attempt to
Rem in with the same barcode.
Testing Rem in the same pouch twice. The user should then either receive an error message, or the
5.7.6 Required? system should reject the second attempt to Rem in with the same barcode.
5.7.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 14
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.8 6.2 Remming Out bug Issue 2
Item I Component Commentary
Horizon System .
Sai. Affected Legacy Horizon.
While Remming out some coins, a Postmaster scanned .an incorrect pouch barcode. On being
prompted to Cancel or Retry with the correct barcode, the Postmaster pressed Cancel, but
5.8.2 I Description before the reversal operation completed, the Postmaster was able to press the Home button,
which would normally be inactive, leading to the remittance being moved to the Suspense
Account.
5.8.3, I Dates May 2005
The Postmaster in this case was trying to Rem out £100 of Sp coins, but on scanning the stock
pouch barcode, Horizon displayed the message "Incorrect Pouch Type", presumably because
the barcode was of the incorrect type to be used for coins. On then being presented with the
option to Cancel, or Retry scanning another barcode, the Postmaster pressed Cancel, which
caused Horizon to begin reversing the Rem out.
5.8.4 I What Happened During the reversal process, the Home button was briefly displayed and was pressed by the
Postmaster, resulting in the remittance of £100 being transferred to the Suspense Account,
instead of being cancelled. The £100 now in the Suspense Account had no correlating pouch ID
and so could not be removed.
The underlying issue is that the Home button should have been disabled at all times during this
process, but it is believed that the counter on this occasion must have been running unusually
slowly for the Home button to have been active for long enough to be pressed.
Technical process for Remming has changed, and no longer works in this way. It is impossible
to duplicate this issue within the current system as the technology has moved on (at the
codebase and at the hardware level).
5.8.5 I Technical Analysis
y op
5.8.6 I TestingRequired? I \. testing can be performed for this scenario.
5.8.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 15
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.9 07 Local Suspense Account issue
Item I Component Commentary
Horizon System . oo . .
5.9.1. I affected Horizon Online Live Pilot, and Horizon Online.
5.9.2. I Description When completing a SU rollover, having experienced a discrepancy, Postmasters were
repeatedly asked how they wanted to settle the discrepancy and were unable to rollover.
5.9.3 I Dates April to September 2010
When undertaking an SU rollover, the normal process is:
1. Postmaster clears the Suspense Account and presses ‘confirm! to complete the rollover.
2. Postmaster returns to the screen asking how the discrepancy is to be cleared.
3. Postmaster then selects one of the settlement options to make good the discrepancy.
4. Once the settlement option is selected, the Postmaster receives confirmation of the SU
5.9.4 I What Happened rollover.
The effect of this bug was that after step 3 above, instead of moving on to step 4, Horizon
Online reverted back to again asking the Postmaster to select the settlement option.
The underlying problem was that the interface between the counter and the BAL was not
working correctly in certain circumstances, the BAL would send a message to the counter that
could not be understood.
5.9.5 I Technical Analysis If a Stock Unit roll over is successful when there a discrepancy which has been settled is present,
then this issue is no longer affecting Horizon.
5.9.6 I Testing Required? I Settle a discrepancy after starting a stock Unit Rollover. There are no error messages and the
user is not asked again to settle the discrepancy.
5.9.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 16
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.10 8.1 Recovery Issues - Issue 1
Item I Component Commentary
Horizon System . oo . .
5.10.1. I attected Horizon Online Live Pilot, and Horizon Online.
A user experienced a failed transaction on one SU, then concurrently logged into another SU to
5.10.2 I Description invoke recovery for the failed transaction; it recovered on the correct SU, but the two SUs were
in different TPs. This scenario lead to a loss in one TP, then a gain in the next. This arose during
the HNG-X Live Pilot and was fixed prior to full rollout.
5.10.3 I Dates April 2010
The Incident leading to identification of this bug occurred in a Crown branch on 14-Apr-2010:
1. Aclerk added a banking withdrawal to the basket on counter 9 but did not settle the
basket.
2. The same clerk then logged on to counter -10 without logging off counter 9, receiving
the message that if they continue the log in on 10, they would be forced to log out from
9.
5.10.4 I What Happened 3. Counter 9 session was terminated, and 3 disconnected session receipts were printed
showing that there was an outstanding session that required recovery.
4. Adifferent clerk then logged in to counter 91 while simultaneously logged on to counter
1 and invoked the recovery process against that incomplete basket.
5. The basket was recovered but written into an incorrect TP.
It was determined that in this case the effect of this bug occurred due to the sequence of
events involving the clerks being logged in simultaneously on different SUs.
5.10.5 I Technical Analysis I Reproduce steps above to test if the same outcome of a loss in one TP and a gain in the next
can arise.
5.10.6 I Testing Required? I Validate if a user is correctly logged out of one SU when they attempt to log into a second, if
the two SUs are in different TPs. Check that any recovery is against the appropriate SU.
5.10.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 17
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.11 8.2 Recovery Issues - Issue 2
Item I Component Commentary
Horizon System . Co . .
5.11.1. I attected Horizon Online Live Pilot, and Horizon Online.
There were multiple Peaks and KELs raised for failed transaction recoveries that were
successfully detected via routine monitoring where POL was notified so the discrepancies could
be corrected.
5.11.2 I Description
5.11.3 I Dates 2010 to 2018
The multiple Peaks and KELs were not seen as related to each other. The main KEL, which is the
KEL that this is referred to when a “State 4” failed recovery is identified via automatic
monitoring.
Recovery processes are part of Horizon Online and are designed to mitigate against the risk of
transactions failing due to interruptions such as power, network, communication, or hardware
5.11.4 I What Happened failures which are risks that cannot be completely eliminated. There were instances where the
recovery process had failed. This was a known risk that could not be eliminated. Automated
failed recovery reports are run each day as part of the Reconciliation Service to identify such
failures. These reports were sent to POL so that TCs can be issued to branches.
Although the KEL and the Peaks referred to instances where recoveries failed, they were a
record of the Reconciliation Service that was provided to POL so the failures could be
corrected.
5.11.5 I Technical Analysis I Reproduce various recovery failures to confirm that they can happen and test that they are
detected by routine monitoring.
5.116 I Testing Required? I Confirm that the Data Reconciliation System will place a transaction into State 4 if it is
unrecognised.
5.11.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 18
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.12 09 Reversals
Item I Component Commentary
Horizon System .
5.12.1. Affected Legacy Horizon.
A software error resulted in an issue with reversals of Remming in transactions. Instead of
reversing the transaction, the amount of the transaction doubled. This bug was introduced as a
result of another fix.
5.12.2 I Description
5.12.3 I Dates April 2003 to Jun 2003
A Postmaster was trading on one SU and Remmed in £113,910 of cash but having failed to
move to another SU to continue trading, attempted to reverse all of the transactions on the
first SU. Instead of the balance returning to zero, the Rem in doubled to £27,820. On calling the
POL helpdesk (NBSC), the Postmaster was advised to attempt the reversal again, resulting in an
5.12.4 I WhatHappened I error message indicating that first attempt at reversal had completed successfully.
The issue was caused by a software error that had been introduced as a result of the fix for
another issue. The bug was that Horizon applied the wrong mathematical symbol when
reversing Rem in transactions, applying the same mathematical operator (+ or -) as the original
Rem, instead of the opposite.
5.12.5 I Technical Analysis I The original scenario on Legacy Horizon cannot be replicated, as the code which causes this
defect has been replaced and is no longer part of the Horizon system.
- ae
5.12.6 I Testing Required? I 14, testing can be performed for this scenario.
5.12.7. I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 19
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.13 10.1 Data Tree Build Failure discrepancies — Issues 1
Item I Component Commentary
Horizon System .
5.13.1. Affected Legacy Horizon.
The effects of these issues were that Horizon displayed incorrect information on screen. The
data tree was the means used in Legacy Horizon to construct a record of the transactions
within given Balancing Periods. The underlying problem was one of error handling, in that
Legacy Horizon had no means of creating a warning if any errors occurred during the creation
of the data tree.
The Peaks related to this issue relate to errors in constructing the data tree, due either to
problems in reading the relevant transactions from the disks (potentially hardware issues), or
in the Reference Data that was used to define the data tree.
5.13.2 I Description
A Postmaster reported a £43,000 discrepancy due to a temporary error (possibly a disk error)
causing an erroneous data tree to be built without any warning. Effectively, the bug is the lack
of warning that there had been an error.
5.13.3 I Dates November 1999 to late 2000
In November 1999, after balancing SUs and doing an office snapshot, a Postmaster found that
the snapshot showed a £43,000 discrepancy which was known to be wrong. The effect of the
bug was to cause an incomplete data tree to be built without any warning being displayed,
thereby creating an incorrect office snapshot. The underlying transaction data was not
5.13.4 I WhatHappened I affected, and if the snapshot had been re-run it may have produced a correct snapshot.
The Postmaster followed the normal procedure in rolling over and made good any
discrepancies in the process. However, since this roll over contained incorrect data (as a result
of the incorrect office snapshot), this meant that a false discrepancy was accepted into the
branch account and the incorrect shortfall was committed to the branch account as a loss.
5.13.5 I Technical Analysis I ThiSecror couldonly occur on Legacy Horizon counters and therefore cannot be replicated.
; op
5.13.6 I Testing Required? I 11, testing can be performed for this scenario.
5.13.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 20
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.14 10.2 (i) Data Tree Build Failure discrepancies — Issues 2(i) PC0121925
Item I Component Commentary
Horizon System .
5.14.1. Affected Legacy Horizon.
The effects of this issues were that Horizon displayed incorrect information on screen. The data
tree was the means used in Legacy Horizon to construct a record of the transactions within
given Balancing Periods. The underlying problem was one of error handling, in that Legacy
Horizon had no means of creating a warning if any errors occurred during the creation of the
data tree.
5.14.2 I Description The Peaks related to this issue relate to errors in constructing the data tree, due either to
problems in reading the relevant transactions from the disks (potentially hardware issues), or
in the Reference Data that was used to define the data tree.
A Test SU on a Fujitsu Test Rig experienced a gain following a cash declaration and rolling over
into the next TP, the discrepancy being the value of transactions performed on the SU after
rollover.
5.14.3 I Dates June to July 2005 (in Test only).
This issue was initially raised by POL when a Test SU being operated on a Test Rig experienced
a gain of £45.05 following a cash declaration and roll into Branch Trading. The amount of the
5.14.4 I WhatHappened I 4:.-repancy was the eash Vall@of the transactidhs performed on the SU after rollover. The
issue occurred as a result of Riposte failing to notify the data tree of new transactions
occurring.
5.14.5 I Technical Analysis I this error could only occur on Legacy Horizon counters and therefore cannot be replicated.
°
5.14.6 I Testing Required? I 11, testing canbe performed for this scenario.
5.14.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 21
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.15 10.2 (ii) Data Tree Build Failure discrepancies — Issues 2(ii) PC0132133
Item I Component Commentary
Horizon System .
S$.i5.1. Affected Legacy Horizon.
The effects of this issue were that Horizon displayed incorrect information on screen. The data
tree was the means used in Legacy Horizon to construct a record of the transactions within
given Balancing Periods. The underlying problem was one of error handling, in that Legacy
Horizon had no means of creating a warning if any errors occurred during the creation of the
5.15.2 I Description data tree,
The Peaks related to this issue relate to errors in constructing the data tree, due either to
problems in reading the relevant transactions from the disks (potentially hardware issues), or
in the Reference Data that was used to define the data tree.
A Postmaster reported erroneous and inconsistent discrepancies appearing in daily cash report
previews.
5.15.3 I Dates February to January 2008.
The Postmaster reported that, while running previews of daily cash reports, a discrepancy was
reported, which increased and then disappeared on re-running the report over the course of a
twenty-minute period.
5.15.4 I WhatHappened I The error was due to transactions carried out after a SU rollover not being added to the data
tree. The underlying cause was that the mechanism to notify the data tree of new transactions
was switched off as result of a bug when Cancel was pressed on a certain message during a SU
rollover.
5.15.5 I Technical Analysis I This error could only occur on Legacy Horizon counters, as it is related to Riposte and therefore
cannot be replicated, as Riposte is no longer part of Horizon.
5.15.6 I Testing Required? I No testing can be performed for this scenario.
5.15.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 22
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2021
5.16 11.1 Girobank discrepancies — Issue 1
Item I Component Commentary
Horizon System .
5.16.1. Affected Legacy Horizon.
Giro transaction reversals carried out after the report cut-off time were not included on the
daily Giro report for that day, nor in the same report for the next day. Despite this, the
5.16.2 I Description transaction reversals would have been recorded correctly in the weekly office Cash Account
report. The system was working as designed, so this was not regarded as a bug, error, or
defect.
5.16.3 I Dates May 2000.
Fujitsu PinICLs (an earlier form of Peak) record several instances of Giro bank reporting
differences in the value of Giro transactions between the daily Giro reports and the weekly
Cash Account reports at certain branches. These differences were the result of a Giro
transaction being entered and reversed, with the reversal being performed after the report
had already been cut-off. The reversal would then not be included in a further run of the daily
report for that clay, nor on the following day.
5.16.4 I What Happened The Peak notes that the system was working as designed, and there was no reason to believe
that data was not being recorded correctly. The Horizon OPS (Office Platform System) Report
and Receipts Design document [SD/DES/005] confirms the behaviour: a transaction and its
subsequent reversal would be suppressed from the report, and if a transaction was reversed
after a report was cut off, then only the reversal would be suppressed (because the transaction
has already appeared on the report prior to cut-off and reversal). It is not clear to Fujitsu what
method POL would have advised Postmasters to use in the event that it was necessary for such
reversal transactions to be carried out after the report cut-off.
This is not a code defect and looks to be a design / business flow issue.
5,165 I Technical Analysis I For this specific item the daily roll-over is 7pm. Any reversals post 7pm flow into the next day
report. Cut-off is to facilitate batch runs. The system no longer works in the way described in
this issue so this could not happen in the same way again.
5.16.6 I Testing Required? I No testing can be performed for this scenario.
5.16.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 23
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.17 11.2 Girobank discrepancies — Issue 2
Item I Component Commentary
Horizon System .
S273. Affected Legacy Horizon.
The same Giro deposit was included on two successive daily reports as a result of being
committed during a particular window of time ona shared SU. It was noticed by Fujitsu while
5.17.2. I Description investigating 11.2 Girobank discrepancies — Issue 1 above, and a fix was applied to prevent
reoccurrence. It appears to be another instance of the bug recorded, which is included in 11.3
Girobank discrepancies Issue 3.
5.17.3 I Dates May 2000.
An £81 Giro deposit was included on two consecutive daily reports. This was because the
transaction was entered in a very small window of time between two system calls being
5.17.4 I What Happened undertaken, resulting in the duplication. It was identified that the problem occurred when
using a shared SU to display and cut off a daily Giro withdrawal or deposit report on one
terminal at the same time as performing a Giro transaction to the same SU on another
terminal. The weekly reports were unaffected.
The original scenario on Legacy Horizon cannot be replicated as reversals now work completely
5.17.5 I Technical Analysis I sitterently. Cut-off is now declared by the branch database (7pm). The system no longer works
in the way described in this issue so this could not happen in the same way again.
5.17.6 I Testing Required? I No testing can be performed for this scenario.
5.17.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 24
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.18 11.3 Girobank discrepancies — Issue 3
Item I Component Commentary
Horizon System
5.18.1. Affected Legacy Horizon.
A discrepancy occurred between the daily Giro report and the office daily report due toa
transaction being carried out on a shared SU by one user while another user was printing and
cutting off the daily report.
5.18.2 I Description
5.18.3 I Dates August 2000.
The Peak records that a Postmaster reported £20 and £628.25 discrepancies between the
Counter Daily Giro Deposit Report and the Office Daily Giro Deposit Report. The issue was
diagnosed as arising out of the use of a shared SU. There was a window of time between a user
printing and cutting-off a report, during which if another user was to perform a transaction,
that transaction may not show on the report.
The weekly reports were unaffected. This bug appears to be identical to 1.17 - 11.3 Girobank
discrepancies — Issue 2.
5.18.4 I What Happened
In the other Peak included in this Issue, a Postmaster attempted to re-enter two transactions
that were incorrectly believed to be missing but did so before cutting off the report. The
weekly reports, when checked, were found to be correct. This Incident appears to be the same
as those in 11.1 Girobank discrepancies - Issue 1.
The original scenario on Legacy Horizon cannot be replicated. Specific issue with these two
items was the data present on the screen from the local Riposte instance (which is depreciated
5.18.5 I Technical Analysis I now).
The specific Girobank action (which is no longer performed) does not impact the current
process (which has been updated to use BRDB).
5.18.6 I Testing Required? I No testing can be performed for this scenario.
5.18.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 25
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.19 11.4 Girobank discrepancies — Issue 4
Item I Component Commentary
5.19.1. I Horizon System Affected Legacy Horizon.
A discrepancy occurred between the daily Giro report and the office daily report
5.19.2 I Description due to a cut-off being performed on one counter despite a failed attempt to print a
transaction on another counter.
5.19.3 I Dates July 2001
A branch Cash Account showed two Giro deposits of £1,503, but the reports
showed only one. The discrepancy was caused under specific circumstances:
1. An attempt was made to print a report on one counter, but the print script
did not complete.
2. Ona separate counter, a transaction was entered which should have
appeared on the still incomplete report.
3. Back on the first counter the report print was retried, but the print failed
(for example due to the
4. printer being switched off).
5. Despite the print failure, the report that failed to print was still cut off,
missing out the transaction from the other counter.
Note that overall accounts were unaffected, but the transaction was missing from
the reports.
5.19.4 I What Happened
5.19.5 I Technical Analysis This error could only occur on Legacy Horizon counters (Riposte) and therefore
cannot be replicated.
5.19.6 I Testing Required? No testing can be performed for this scenario.
5.19.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 26
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.20 11.5 Girobank discrepancies — Issue 5
Item I Component Commentary
Horizon System .
5.20.1. Affected Legacy Horizon.
5.20.2 I Description Two branches noticed discrepancies between the daily Giro report and the office daily report,
although weekly reports were unaffected.
5.20.3 I Dates February - April 2002.
In one instance, the Office Balance Snapshot figures were double the figures on the Cash
Account snapshot, although the Office Balance report and the Cash Account figures were
unaffected.
5.20.4 I What Happened I {n another instance, a Postmaster found that a Giro Daily Report printed the whole of the
previous week's deposits.
Both issues related to the same underlying problem although the KEL raised for this purpose
was only referenced in one further Incident.
5.20.5 I Technical Analysis I oy: ginal scenario on Legacy Horizon (Riposte) cannot be replicated.
5.20.6 I Testing Required? I No testing can be performed for this scenario.
5.20.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 27
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.21 11.6 Girobank discrepancies — Issue 6
Item I Component Commentary
Horizon System .
$21.1. Affected Legacy Horizon.
A branch believed that two Giro deposits did not appear on the reports run either on the same
day, or the next day. However, the Postmaster was mistaken, and this was not a bug, error, or
defect.
5.21.2 I Description
5.21.3 I Dates May 2000.
A Postmaster reported that two Giro deposits had not appeared on the Giro Deposits report
5.21.4 I What Happened __I run on the same day as the transaction, nor on the next day's report. Following investigation by
Fujitsu SSC, it transpired that the transactions were in fact included on the report the following
day.
5.21.5 I Technical Analysis I wot a code defect. This was a misunderstanding and was clarified by the Support Centre.
5.21.6 I Testing Required? I No testing is required to be performed for this scenario.
5.21.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 28
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.22 12.1 Counter-replacement issues — issue 1
Item I Component Commentary
Horizon System .
5.22.1. Affected Legacy Horizon.
5.22.2. I Description Following the replacement of a counter hard drive at a single counter branch, messages were
overwritten, resulting in a receipts and payments mismatch.
5.22.3 I Dates November 2000 to September 2002.
A Postmaster reported a receipts and payments mismatch: receipts were £50,191.70,
payments were £50,023.58, resulting in a £167.12 discrepancy. The discrepancy would have
been flagged to the Postmaster on the Cash Account when attempting to rollover.
This occurred in a single counter branch where the hard drive had been replaced, but the
5.22.4 I WhatHappened I replacement appeared to cause two messages related to an Order Book Control Service (OBCS)
transaction to be overwritten, so that a transaction off 167 .12 was not added to the Cash
Account.
The root cause was Horizon Riposte coming online from recovery mode too early, resulting in
messages being overwritten because they had not been committed to the datacentre.
5.22.5 I Technical Analysis I This error could only occur on Legacy Horizon counters (Riposte) and therefore cannot be
replicated.
5.22.6 I Testing Required? I No testing can be performed for this scenario.
5.22.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 29
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.23 12.2 Counter-replacement issues — issue 2
Item I Component Commentary
Horizon System .
5.23.1. Affected Legacy Horizon.
A branch had two counters removed, leaving it as single counter branch. As the remaining
single counter did not have a mirror disk; the branch had no replication of data if it was not
connected to the datacentre.
5.23.2 I Description
5.23.3 I Dates March 2006.
A branch had three counters and two counters were removed, leaving it as single counter
5.23.4 I What Happened _I branch. As the remaining single counter did not have a mirror disk; the branch had no
replication of data if it was not connected to the datacentre; six messages on the counter had
not been replicated to the data centre.
5.23.5 I Technical Analysis I This error could only occur on Legacy Horizon counters (Riposte) and therefore cannot be
replicated.
5.23.6 I Testing Required? I No testing can be performed for this scenario.
5.23.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 30
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.24 12.3 Counter-replacement issues — issue 3
Item Component Commentary
Horizon System .
5.24.1. Affected Legacy Horizon.
5.24.2 I Description Horizon Riposte failed to index messages, which resulted in some items being missed from the
receipts side of the Office Balance Report.
5.24.3 I Dates February 2008.
Horizon Riposte failed to index four messages which resulted in some items being missed from
the receipts side of the Balance Report. It is unknown how common this issue was. The Peak
5.24.4 I What Happened I Fotes that the branch did not experiencadlilibpancy as a result because this was a
reporting issue only; indexes are not used when replicating data and so cash/stock were
unaffected.
5.245 I Lechnical This error could only occur on Legacy Horizon counters (Riposte) and therefore cannot be
ae Analysis ;
replicated.
Testing
5.24.6 I Required? No testing can be performed for this scenario.
5.24.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 31
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.25 13 Withdrawn stock discrepancies
Item Component Commentary
Horizon System .
o:25-15 Affected Legacy Horizon.
Discrepancies could occur when a Postmaster declared that they held stock of a withdrawn
5.25.2 I Description product and then accepted the resulting discrepancy on the system. The system would re-
introduce the withdrawn product into the system, and the discrepancy would continue to
rollover.
5.25.3 I Dates July 2010 to September 2011.
A Postmaster returned some withdrawn stock to POL after the reference data change relating
to that stock had been made, without performing the Rem out. This meant that the value of
the items remained in the branch account, resulting in a shortfall to the value of the
withdrawn stock.
The next TP balance showed the shortfall, prompting the Postmaster to make good, resulting
5.25.4 I What Happened I ina TC being issued by POL to balance the shortfall in the next TP.
The effect of the bug was that the withdrawn stock was re-introduced in November 2010 as
part of the branch stock after the subsequent rollover, and this. occurred again in the following
two months. The reintroduction was not noticed by the Postmaster in December (because
there were some unrelated losses that were partially offset by the TC), but noticed in January
2011 because combined with the reintroduction in December 2010, the stock value of that
item had doubled.
Technical
5.25.5 I analysis This specific incident was a one-off and cannot be recreated.
Testing . - .
5.25.6 I Required? No testing can be performed for this scenario.
5.25.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 32
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.26 14.1 Bureau discrepancies — Issue 1
Item I Component Commentary
Horizon System . .
5.26.1. I attected Horizon Online.
A Postmaster tried to pre-order two currencies. A network timeout occurred after the second
5,262 I Description was added to the basket. The Postmaster attempted to cancel the whole order, but only the
first currency was successfully cancelled, leaving a shortfall for the amount of the second
currency.
5.26.3 I Dates August 2017 - November 2017
A Postmaster attempted to pre-order two currencies for a customer: £1,000.07 in Indonesian
Rupiah; and £204.59 in Singaporean dollars. The order for Rupiahs was successful; however, at
the point the dollar order was added, there was a network timeout. When the system came
5.26.4 I What Happened back online, a warning message stated that the second order may not have succeeded,
although the basket and transaction log were showing both orders.
As the customer's receipt showed only the Rupiah order, the Postmaster attempted to cancel
the whole order of both currencies. The cancellation only succeeded for the Rupiah order,
leaving a £204.59 shortfall in respect of the dollars.
5,265 I Technical Analysis I Bureau has had a large redesign since 2017, and the process has changed - rather than
individual transactions, the transactions are now merged into one stream.
Perform a bureau Pre-Order transaction with two currencies. when submitting the order, the
5.26.6 I Testing Required? I first currency is successful, but the second one times out. Confirm that Horizon handles this
correctly.
5.26.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 33
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.27 14.2 Bureau discrepancies — Issue 2
Item I Component Commentary
Horizon System . .
5.27.1. I affected Horizon Online.
5.27.2 I Description This issue involved a one-sided transaction; the branch had a record of a sale of Euros (€4,500)
but this was not reflected on the POLSAP system.
5.27.3 I Dates December 2017 - May 2018.
5.27.4 I What Happened This issue related to a one-sided transaction in which a branch had a record of a sale of Euros,
but it was not recorded in POLSAP, leading to a discrepancy.
It is understood that the error was within the POLSAP system. POLSAP was replaced with CFS -
but same files are sent from Horizon through today.
5.27.5 I Technical Analysis
Perform a sell Euros transaction on Horizon. Confirm the transaction appears in the BTF and
5.27.6 I Testing Required? I BTR files. Send the BTF and BTR files to Accenture to confirm that the transaction processes
successfully.
5.27.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 34
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.28 15.1 Phantom Transactions — Issue 1
Item I Component Commentary
Horizon System .
5.28.1. Affected Legacy Horizon.
Some Postmasters reported that items and transactions appeared and disappeared without
any user input.
5.28.2 I Description After extensive monitoring, it was concluded that user error could not be ruled out in any of
the known circumstances. It is worth noting that this collection of issues arose and then ceased
within a few months of the branches first going live with Horizon in 2001. Ultimately, the issues
appear to relate to insufficient training, and, in some cases, equipment failures which were
then resolved.
5.28.3 I Dates April 2001 - November 2001.
A Postmaster reported that items and transactions would appear and disappear from the
screen without any user input. The Peak contains multiple reports by the Postmaster of
separate instances of this type of error, but also reports of errors in various other branches.
5.28.4 I What Happened The Peak opens with a record that the Postmaster had made a previous complaint that had
been closed without his agreement, and that the Postmaster had already had to pay to cover
losses incurred as a result of the problems. It records the Postmaster had previously had
disagreements with Post Office Counters Limited (POCL) and Fujitsu over whether the
problems were caused by user error, or issues with Horizon.
5.28.5 I Technical Analysis I This issue was unique and non-reproducible, as it looked to be a site issue (suspect interaction
of the building with the terminal).
5.28.6 I Testing Required? I No testing can be performed for this scenario.
5.28.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 35
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.29 15.2 Phantom Transactions — Issue 2
Item I Component Commentary
Horizon System .
5.29.1. Affected Legacy Horizon.
A Postmaster reported that a receipt containing three transactions printed without any user
input. This was, however, standard functionality that occurred if a user was automatically
logged off due to inactivity after having entered, but not completed, transactions.
5.29.2 I Description
5.29.3 I Dates August 2000.
A Postmaster reported that a receipt containing three transactions printed without any user
input.
Horizon automatically logs a user out after a period of inactivity, a standard security measure
of many IT systems. If the user has recorded, but not completed, some transactions in the
stack, then when the systems automatically logs off, it will complete these transactions and
5.29.4 I What Happened _I assume payment was made by cash. The receipts are then printed to make it clear to the
Postmaster that it has happened.
Fujitsu's investigation showed that the transactions were held in a suspended session hence
they were not complete when the user was logged out. The assumption was that they were
inadvertently placed in suspense by the Postmaster.
This was not a bug, but functionality intentionally designed into the system, based on POL's
requirement.
5.29.5 I Technical Analysis Validate how transactions are handled post-recovery. The transaction is progressed when
logged out and the transaction is completed with receipt printed.
Add three items to the Horizon basket and place in a suspended session. Leave the counter for
5.29.6 I Testing Required? I an hour until log off is enforced. Confirm that the suspended session completes to cash and the
receipt is printed
5.29.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 36
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.30 15.3 Phantom Transactions — Issue 3
Item I Component Commentary
Horizon System .
5.30.1. Affected Legacy Horizon.
Two counters in the same branch had certain differences in the icons displayed on screen. One
counter had received the latest Horizon Riposte release (which changed the button text), the
other had not, so the two counters were one version apart.
5.30.2 I Description
5.30.3. I Dates August 2000.
The Postmaster that reported 15.2 Phantom Transactions - issue 2, also reported at the same
5.30.4 I WhatHappened I time that there were differences between the icons displayed on the two counters in the
branch.
5.30.5 I Technical Analysis I oyiginal scenario on Legacy Horizon (Riposte) cannot be replicated.
: “ed?
5.30.6 I Testing Required? I 1, testing can be performed for this scenario.
5.30.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 37
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.31 16.1 Reconciliation issues - Issue 1
Item I Component Commentary
Horizon System .
S311. Affected Legacy Horizon.
Discrepancies were reported by automated BAU reconciliation reporting, related to two
transactions (£8.06 and £0.08, totalling £8.14) that were brought forward values from the
previous week's Cash Account.
5.31.2 I Description
5.31.3 I Dates March 2000 -August 2000.
At the end of each working day, the counter calculated information for the Cash Account in
two independent ways and ensured that they matched, then a report was generated of any
instances of mismatches. The Peak was raised as a result of that process which showed a
5.31.4 I WhatHappened _I discrepancy of £8.14. The root cause was identified in a related Peak as being code that, in the
event of a particular sequence of operations being carried out by the Postmaster, would cause
transactions to be brought forward from the previous week's Cash Account. The apparent
discrepancy was therefore a reporting issue, and although the scenario in which it arose was
thought to be relatively unusual, it was treated as a bug to be fixed.
5.31.5 I Technical Analysis I Giginal scenario on Legacy Horizon (Riposte) cannot be replicated.
- _
5.31.6 I Testing Required? I 1, testing can be performed for this scenario.
5.31.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 38
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.32 16.2 Reconciliation issues - Issue 2
Item I Component Commentary
Horizon System .
5.32.1. Affected Legacy Horizon.
5.32.2 I Description A false discrepancy of 1p was detected by automated BAU reconciliation reporting;
investigation showed no actual discrepancy in the branch.
5.32.3 I Dates April 2002 -August 2002.
Daily BAU reconciliation reporting identified discrepancies between totals produced at the
counter (1p) and those produced at the data centre (zero). Fujitsu's investigations identified
that the discrepancy was due to the way that the host re-calculated the totals. from the branch
5.32.4 I WhatHappened I ata when carrying out the reconciliatigfepeck Welles generated as 0.01 (1p) were being
stored as 0.0099 which was then treated as zero and therefore ignored, and not recorded for
the purpose of the report. This bug was fixed in order to avoid further instances of false
mismatches appearing on report TPSC268A.
5.32.5 I Technical Analysis Original scenario on Legacy Horizon (Riposte) cannot be replicated.
I?
5.32.6 I Testing Required? I iy, testing can be performed for this scenario.
5.32.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 39
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.33 16.3 Reconciliation issues - Issue 3
Item I Component Commentary
Horizon System .
S33.1, Affected Legacy Horizon.
5.33.2 I Description Related to a Test system, not Live, therefore does not affect the Postmasters.
5.33.3 I Dates July 2000 -August 2000.
The Peak was raised by a tester explicitly checking for issues in a test environment. A report
showed a difference between the number of files recorded as being transferred to TIP and the
number of files actually transferred. The root cause was that when the report was run it was
not accounting for the files already counted. There is no suggestion in the Peak of any issues
5.33.4 I What Happened
with the underlying data being transferred to TIP, only with the report.
5.33.5 I Technical Analysis I thi. item occurred within a Test environment and was not present in the Live environment.
; op
5.33.6 I Testing Required? I 1, testing is required for this scenario,
5.33.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 40
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2021
5.34 16.4 Reconciliation issues - Issue 4
Item I Component Commentary
Horizon System .
5.34.1. Affected Legacy Horizon.
5.34.2 I Description Automatic detection of a receipts and payment mismatch of £4,464.46, related to the data
tree issues described above in section 5.10.
5.34.3 I Dates May 2000.
Areceipts and payment mismatch was automatically detected. Investigation identified the
immediate cause of the imbalance in the Cash Account being a result of a failure in the EPOSS
5.34.4 I WhatHappened I bata server. The root cause was related to a data tree build failure (documented as 10.1 Data
Tree Build Failure discrepancies issues 1 and 2) that occurred following a hard disk failure in
the branch.
5.345 I Technical Analysis I This error could only occur on Legacy Horizon counters (Riposte) and therefore cannot be
replicated.
; >
5.34.6 I Testing Required? I \ testing can be performed for this scenario.
5.34.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 41
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.35 16.5 Reconciliation issues - Issue 5
Item I Component Commentary
Horizon System .
$35.1. Affected Legacy Horizon.
Data was detected as missing from the Client Transaction Summary (CTS) Report due to new
5.35.2 I Description products with start dates not on the midnight boundary. Although this system was operating
as designed, a fix was made so that this did not reoccur.
5.35.3 I Dates September 2014 - December 2014.
Data was detected as missing from a CTS Report, It was identified that when products with a
start date of 01-Aug-2014 were traded on that date, the metadata for those products did not
5.35.4 I WhatHappened I Jct exist on the Automated Payment S@iee (APS)atabase when the CTS report was written.
The root cause was identified as products being introduced with start dates/ times that were
not on a midnight boundary; in this particular case the start time was 00:00:02.
Need to force a timestamp data with Reference Data (within the Fujitsu domain and not the
5.35.5 I Technical Analysis I Atos/POL Reference Data). Also need to be able to transact before it becomes active.
File would have come across from MDM.
5.35.6 I Testing Required? I Force a timestamp data with Reference Data (within the Fujitsu domain) Transact before it
becomes active and confirm if problems arise when such products are traded.
5.35.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 42
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.36 16.6 Reconciliation issues - Issue 6
Item I Component Commentary
Horizon System .
5.36.1. Affected Legacy Horizon.
5.36.2 I Description A difference was found between a branch's figures and the CTS report.
5.36.3 I Dates September 2010.
A Postmaster found there was a difference between their branch figures and the CTS report
5.36.4 I What Happened and reported it to the Fujitsu helpdesk (HSD). Investigation by Fujitsu SSC found that the root
cause was an issue with POLSAP, so the Peak was closed as POLSAP was not supported by
Fujitsu SSC.
5.36.5 I Technical Analysis I It is understood that the error was within the POLSAP system. This did occur in legacy Horizon
as a one off and unlikely to reoccur.
: “ed?
5.36.6 I TestingRequired? I 14 testing can be performed for this scenario.
5.36.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 43
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.37 17 Branch Customer discrepancies
Item Component Commentary
Horizon System .
5.37.1, Affected Legacy Horizon.
A counter crashed while the user was processing a cash withdrawal transaction. The
5.37.2 I Description Postmaster started the recovery process but did not complete it. The customer did not
receive the money as the transaction did not complete, but the bank did record the
withdrawal.
5.37.3 I Dates March 2008.
A branch counter crashed while processing a cash withdrawal transaction. As a result, Horizon
did not record a completed cash withdrawal. Since the transaction did not complete, the
Postmaster should not have handed over the cash to the customer, and it appears from the
record that the Postmaster did not do so. However, the customer's bank recorded the
transaction as having taken place, hence the customer would suffer the loss of the withdrawal
from their account, but without receiving the cash.
The branch did not log back into the counter after the crash, so the automatic recovery
process was not carried out. (If the recovery process had been completed properly, it would
have recorded a reversal of the failed cash withdrawal, resulting in the customer's bank
returning the money to the customer's account, and no transaction being registered on
Horizon, i.e. it would be as if the transaction had not happened at all).
Fujitsu detected the problem transaction via the automated NB102 report, where it appeared
as a state 4 transaction (an incomplete transaction), which reports discrepancies between the
Financial Institution's (Fl) view of what has happened and Horizon's. In this case, the
discrepancy was that the Fl had authorised a payment/withdrawal on the assumption that the
5.37.4 I What Happened I cash payment had been made, whereas Horizon recorded that there had been no payment.
This report caused the creation of the first Peak.
Having noted that the Postmaster had not logged back into the counter since the event,
Fujitsu contacted the branch and advised the Postmaster to log in to the counter and allow
the writing of the recovery messages to complete. Within around 30 minutes it was confirmed
that the messages had been written, and later that day a BIMS was issued to POL.
However, the next day the transaction again appeared on the NB102 report, this time as a
state E37 (uncleared exception), leading to the creation of the second Peak (PC0156236). It
appeared that on attempting the recovery process, the Postmaster had not allowed it to
complete and had declined the recovery.
The Peak also records that POL had contacted Fujitsu to report that the Fl (Citibank) had
contacted POL to ask why the transaction was showing on their system as an exception. It was
thought that the branch account was in balance, but the customer's account had been
debited, and therefore needed rectifying. Fujitsu advised POL to check with the branch to
confirm that the money had not been paid to the customer, and if that was the case, to notify
the bank of the discrepancy so that the customer account could be corrected.
Technical
Analysi This is not a system error and is working as designed. Review of the process flow for this
nalysis
5.37.5
activity to see if it can be improved / remove possibility of user confusion should be done.
STRICTLY CONFIDENTIAL [Publish Date] 44
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
Testing
5.37.6 I Required? No testing can be performed for this scenario.
5.37.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 45
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.38 18.1 Concurrent logins — Issue 1
Item I Component Commentary
Horizon System .
5.38.1. Affected Legacy Horizon.
5.38.2 I Description A user managed to log on to two counters simultaneously when the first counter was unable to
respond.
5.38.3 I Dates 1999 to 2001.
While printing a final Cash Account on counter 2, the system froze for an hour. Having called
the Fujitsu helpdesk (HSH), the Postmaster was asked to logon to counter 1 to re-try printing
out the final Cash Account, which was successful. Counter 2 was still showing ‘printing report’
as the Postmaster was logging on and printing the report on counter 1. Counter 1 then started
5.38.4 I WhatHappened I to show "no entry sign" icons when the Postmaster logged out. POL NBSC requested Fujitsu to
investigate the fact that the Postmaster had apparently been logged on to two counters
concurrently. There was no evidence of any financial discrepancy.
It was confirmed after investigation by Fujitsu that the Postmaster had been able to log himself
onto the system at both counter 1 and counter 2 at the same time.
The original scenario on Legacy Horizon cannot be reproduced. HGNA now has updated / new
5.38.5 I Technical Analysis I controls regarding user access, and this scenario cannot be duplicated in the current system.
The BRDB now only allows a single login - or it locks the session if you try to logon from a
different counter.
- oS
5.38.6 I Testing Required? I 44, testing can be performed for this scenario.
5.38.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 46
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.39 18.2 Concurrent logins — Issue 2
Item I Component Commentary
Horizon System .
$39.1. Affected Legacy Horizon.
5.39.2. I Description A receipts and payments mismatch were caused by two operations being carried out with
simultaneous logins, although there was no overall loss to the branch.
5.39.3 I Dates 2000.
Areceipts and payments mismatch were reported by a Postmaster to the Fujitsu helpdesk
(HSH). The Postmaster reported that they had transferred £9,250 out from, counter 8 by
mistake, when it should have been from counter 1, with £5,590 being transferred in to counter
3 and £3,660 to counter 4. This had occurred while counter 8 was in the process of rolling over,
but 3 and 4 had not yet rolled. As a result, the cash left counter 8 in Cash Accounting Period
(CAP) 18 and arrived in counters 3 and 4 in CAP 17.
5.39.4 I WhatHappened I Cap 18 was therefore in surplus, because £9,250 was transferred out and never back in within
the same CAP, while CAP 17 had a gain, because £9,250 was transferred in but there was no
corresponding transfer out without the same CAP. The Postmaster then rolled over the office
for CAP 17, accepting the discrepancy.
Fujitsu's investigation indicated that the immediate cause of the error was that the user rolled
counter 3, while logging in and processing a transfer out on counter 4, so was logged in to both
counters concurrently.
No test suggested. Original scenario on Legacy Horizon (Riposte) cannot be replicated, as the
Riposte system is no longer part of Horizon.
5.39.5 I Technical Analysis
7 fred?
5.39.6 I Testing Required? No testing can be performed for this scenario.
5.39.7. I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 47
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.40 19 Post & Go/TA discrepancies in POLSAP
Item I Component Commentary
Horizon System
5.40.1. Affected Horizon Online. Only branches with Post & Go terminals could have been affected.
This occurred in a scenario in which Horizon was receiving Post and Go (PG) data for six
separate PG tills at a branch, but only four of the tills had associated SUs. This caused the
entire subfile for the branch to be held, and the transaction data was not sent to POLSAP.
5.40.2. I Description
5.40.3 I Dates 2012.
A branch was found to have many entries in the "Subfiles_on_hold" report. Horizon was
receiving PG data for six separate Post & Go tills at the branch, but only four of them had
associated SUs. This caused the entire subfile for the branch to be held, and the transaction
data was not sent to POLSAP.
It was noted by Fujitsu SSC that other branches were experiencing similar issues, although the
5.40.4 I What Happened
branches themselves would not notice the issue because it did not affect the transfer of data
from PG terminals to Horizon and therefore did not affect branch accounts. It only affected the
transfer of data outside of Horizon to POL SAP.
The system has substantially changed since this issue arose, and the code which sends the
information has changed. There is a report generated as part of the current process — Post
Office Data Gateway (PODG) which does include information (which is not reflective of the
5.40.5 I Technical Analysis process as in this KEL - the file has changed, it used to be BLE files, which are no longer used).
These reports are still generated and reviewed as required. The solution is significantly
different today than when the original issue was found. Specifically, there is a different
program that prepares the data that gets transferred and it is therefore for Post Office to
verify that the data they are receiving is what they expect.
cs
5.40.6 I TestingRequired? "I 1, testing can be performed for this scenario
5.40.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 48
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.41 20.1 Recovery Failures — Issue 1
Item I Component Commentary
Horizon System . .
5.41.1. I attected Horizon Online.
A Postmaster raised an alleged discrepancy with POL and Fujitsu nine months after the events
5.41.2 I Description in question.
Fujitsu believe the incident to have been a genuine accounting issue, and not caused by any
fault in Horizon.
5.41.3 I Dates September 2012.
A Postmaster rolled her office over with a discrepancy of less than £1, then the following day
performed a daily cash declaration that showed a shortfall of £191.48. The next day one of the
counters suffered a memory dump issue, and the following day the counter was replaced.
A few days later the Postmaster reported a shortfall of £300 and asked the POL helpdesk
(NBSC) if it might be related to the base unit fault or replacement. NBSC passed the Incident to
Fujitsu, and Fujitsu SSC investigations found no evidence of any system errors, and suspected
that the cash shortfall that existed before the memory dump issue was the same shortfall that
was now being reported, in other words it predated the memory dump and the base unit
s.ai4 I What Happened I Teplacement. The issue was passed back to NBSC for investigation as an operational accounting
issue.
Eight months later the Postmaster opened another Incident with the POL helpdesk alleging
that the counter replacement had caused the £300 loss. Fujitsu responded to POL by providing
information from the original Incident earlier in the year, and about the memory dump and the
base unit swap. The Peak also noted that it was not clear what, if any, investigation had been
carried out by NBSC, and that no further Incidents had been raised at the time regarding the
discrepancy. Fujitsu advised POL that if further investigation was required then POL would
need to submit an ARQ request in order to retrieve financial transaction data from the audit
server.
It is understood that the Incident was resolved between NBSC and the Postmaster, with no
error being shown to have occurred in Horizon. The system was working as expected and no
defect or error within the Horizon platform was found.
5.41.5 I Technical Analysis
; a
5.41.6 I Testing Required? I testing is required for this scenario.
5.41.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 49
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.42 20.2 Recovery Failures — Issue 2
Item I Component Commentary
Horizon System . .
5.42.1. I attected Horizon Online.
5.42.2 I Description Asession failed due to a communications / network problem. On restoration of the service, a
Health Lottery transaction failed to recover correctly.
5.42.3. I Dates February 2015.
Auser reported that they were unable to complete a recovery on a counter. The settlement of
the session failed due to a network communications problem. On logging back in, the recovery
process was initiated but the recovery of one of the two transactions in the session failed, and
the user was then unable to log in on that counter.
The root cause was the failure of the AP-ADC recovery script to handle Lottery transactions
5.42.4 I What Happened
fully.
5.42.5 I Technical Analysis I 1+ i, understood that the error was with AP-ADC scripting.
5.42.6 I Testing Required? I Health lottery transactions should be appropriately recovered after network communications
failure.
5.42.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 50
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.43 20.3 Recovery Failures — Issue 3
Item I Component Commentary
Horizon System . .
5.43.1. I attected Horizon Online.
5.43.2 I Description This was a BAU reconciliation incident following a standard process with no evidence of any
failure.
5.43.3 I Dates April 2010.
5.43.4 I What Happened The original issue in the branch leading the reconciliation issue appeared to relate to a cash
withdrawal, but the exact details are unknown.
It is understood that this to have been an example of a routine reconciliation incident, and the
5.43.5 I Technical Analysis I «act scenario that led to it is unknown. This is not a System error or defect — but a BAU
reconciliation error.
I?
5.43.6 I Testing Required? I 1, testing is required for this scenario
5.43.7. I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 51
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2021
5.44 21.1 Transaction Correction Issues — Issue 1
Item I Component Commentary
Horizon System .
5.44.1. Affected Legacy Horizon.
Four Peaks were raised during the testing of Transaction Correction functionality (TC) for the
then future S80 release of the system. These Peaks were not in Live, so could not have affected
branch accounts.
5.44.2. I Description
5.44.3, I Dates January - May 2005.
The Peaks identified were raised by Fujitsu's SV&l team and related to issues which occurred
5.44.4 I What Happened I during the testing of TC functionality for the then future $80 release of the system. Three Peaks
related to the appearance of TC option buttons on the screen, while the other related to the TC
pick list freezing when a TC was received.
These items were raised in the test environment only, and did not occur in the Live
5.44.5 I Technical Analysis I oa yironment. Additionally, the original scenario was related to on Legacy Horizon (Riposte)
cannot be replicated, as Riposte is no longer part of the Horizon system.
; sap
5.44.6 I Testing Required? I 1, testing is requ(redieake performed famabrscenario
5.44.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 52
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.45 21.2 Transaction Correction Issues — Issue 2
Item Component Commentary
Horizon System
5.45.1. Affected Legacy Horizon.
The screen froze when selecting Transaction Correction (TC). This bug was identified on 51
5.45.2 I Description I " ane .
sites, due to formatting of the TCs, soon after the functionality was introduced.
5.45.3 Dates December 2005 - January 2006.
In December 2005, Fujitsu received calls from branches reporting that their screens would
freeze when selecting a TC from the picklist, preventing the branch from dealing with the
outstanding TC. The issue was reported by four branches in relation to a TC for Premium Bond
Sale, and a further 48 branches relating to a Camelot Lottery TC. The issue impacted branches
as they were prevented from rolling over, due to being unable to clear their outstanding TCs.
5.45.4 I What Happened —_I The problem was found to be caused by the code being unable (and not designed) to deal
with some of the formatting used by the POL TC team in preparing some of the TCs. The code
to render the text of the TC on screen attempted to split the blocks of text at a suitable space
between words, but some of the TCs contained long strings of around 80 concatenated
characters causing the code to fail.
5.45.5 I Technical Analysis I Original scenario on Legacy Horizon (Riposte) cannot be replicated.
5.45.6 I Testing Required? I No testing can be performed for this scenario
5.45.7 Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 53
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2021
5.46 21.3 Transaction Correction Issues — Issue 3
Item Component Commentary
Horizon System .
5.46.1. Affected Horizon Legacy
Transaction Corrections (TCs) more than 40 days old were not showing on the TC report
5.46.2 Description which it was possible to request for up to 60 days after the TC was issued. This was due to the
retention period being only 40 days.
5.46.3 I Dates September - October 2010.
A Postmaster contacted the Fujitsu helpdesk (Service Desk) to report an £80 cash loss and
claimed it was caused by a system error. In evidence, the Postmaster provided a processed
TC report generated on 10 September 2010, with a date range between 12 July 2010 to 10
September 2010 (i.e. 60 days). The report showed a TC accepted on 08 September 2010, but
not the TCs accepted on 13 July 2010 and 21 July 2010.
Fujitsu requested (by phone) some additional information from the Postmaster in order to
further investigate the £80 loss, but no further information was available. The Peak records
5.46.4 I What Happened that a check was made by NBSC that confirmed that the TCs missing from the report had
been processed correctly, and that information was passed on to the Postmaster.
Fujitsu Development ascertained that the cause was a bug introduced as part of HNG-X.
Through the picklist on screen, Horizon allowed Postmasters to select a backwards date
range of up to 60 days when generating a processed TC list, but the relevant database only
retained the data for up to 40 days. It was confirmed that the original use case stated that
the TCs should be retained for 60 days, and that because the setting on the database table
was incorrect, this was a bug.
To test a script is needed to update the TC(s) details in the BRDB to reflect an age of 61 and
5.46.5 I Technical Analysis 7
62 days. Thus an “aged" TC can be inserted into the system.
Test that the number of days for which it is possible to request a TC report can be accurately
5.46.6 I Testing Required? -
provided by the report.
5.46.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 54
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.47 22.1 Bugs/errors/defects introduction by previously applied Peak fixes — Issue 1
Item Component Commentary
Horizon System
5.47.1. I affected
Legacy Horizon.
If incorrect keys were pressed while generating a certain report, the screen could freeze.
5.47.2 I Description This was identified on a Training Counter in test, and it was determined that it could also
occur in the live system, but the Peak records no evidence that the issue ever did occur in live.
5.47.3 Dates August - September 2000.
Fujitsu test team that was testing a future release found a bug in the training environment,
described as "Training Counter freezes using transaction log. This manifests itself in training, if
a delegate mis-hears or miskeys a keying sequence in doing a transaction log report."
5.47.4 I What Happened Tests on the software that was currently in use in live determined that if the same sequence
of events was performed, the same problem might arise. There is no evidence recorded that
it had ever arisen in the live system, but it was decided to produce a fix to ensure that it could
not.
5.47.5 I Technical Analysis Original scenario on Legacy Horizon (Riposte) cannot be replicated,
5.47.6 I Testing Required? No testing can be performed for this scenario.
5.47.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 55
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.48 22.2 Bugs/errors/defects introduction by previously applied Peak fixes — Issue 2
Item Component Commentary
Horizon System
5.48.1. Affected Legacy Horizon.
A Postmaster reported a discrepancy between the system cheque figure and the declared
5.48.2 Description figure. It was thought to be due to code regression of the system caused by a fix for another
bug.
5.48.3 I Dates January - September 2004.
POL NBSC reported to Fujitsu that a Postmaster had negative figures in his Cash Account
which the Postmaster could not have entered. Fujitsu contacted the Postmaster to obtain
further information so that the issue could be fully investigated.
A discrepancy occurred between the cheque figure entered on the system and the declared
5.48.4 I What Happened —_I cheque figure; instead of the discrepancy being cleared it was doubled, and cash was also
found to be wrongly adjusted.
It was acknowledged that this was a bug introduced as a result of code regression occurring
when fixing another issue.
5.48.5 I Technical Analysis I Original scenario on Legacy Horizon (Riposte) cannot be replicated.
5.48.6 I Testing Required? I No testing can be performed for this scenario.
5.48.7 Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 56
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.49 Bugs/errors/defects introduction by previously applied Peak fixes — Issue 3
Item Component Commentary
Horizon System
5.49.1. Affected Legacy Horizon.
Two Peaks were raised in the Test environment and not in Live. A bug caused a discrepancy to
5.49.2 I Description
appear on the Counter Detected Reconciliation Errors report
5.49.3 Dates June - August 2000,
Within the test environment only, a new bug that caused a discrepancy to appear on the
5.49.4 I What Happened __I Counter Detected Reconciliation Errors (TPSC252) report was introduced as a result of fixing
an existing issue in a previous test Peak.
There was no impact on the Postmasters as this was in the Test environment. Additionally,
5.49.5 I Technical Analysis I the original scenario was on Legacy Horizon (Riposte), and cannot now be replicated, as
Riposte is no longer part of the Horizon system.
5.49.6 I Testing Required? I No testing is required to be performed for this scenario.
5.49.7 Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 57
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2021
5.50 23.1 Bureau de change -— Issue 1
Item I Component Commentary
Horizon System .
5.50.1. Affected Legacy Horizon.
woe A Postmaster reversed a currency transaction but apparently performed the process in an
5.50.2 I Description . -_
unexpected manner. There was a second instance of a similar error a few months later.
5.50.3 I Dates December 2005 -July 2006.
The Postmaster had attempted to reverse a transaction for the sale of €1,000 (worth £750) but
reversed the settlement instead. The Postmaster then attempted to compensate for the
resulting discrepancy by adjusting the stock, leaving the margin for the transaction as a loss of
£30.
5.50.4 I What Happened _I Fujitsu identified that the Postmaster did not reverse the transaction correctly, thereby causing
the loss. Fujitsu SSC made several suggestions in the Peak: that the POL Operations Manual
might be reviewed for clarity; that it was important that the POL helpdesk (NBSC) understand
how the process worked so that they could diagnose such issues when they arose; and that a
warning might be added if a transaction being reversed is cash.
The original scenario on Legacy Horizon cannot be replicated.
5.50.5 I Technical Analysis I The existing process flows should be examined to see how settlements are reversed (and why
they are reversed). So, it can be determined if this process flow can be simplified.
5.50.6 I Testing Required? I No testing can be performed for this scenario.
5.50.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 58
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.51 23.2 Bureau de change — Issue 2
Item I Component Commentary
Horizon System .
SSL1. Affected Legacy Horizon.
A Postmaster reported a discrepancy after Remming out: currency, reversing it, then re-
5.51.2 I Description Remming them out. This was identified as being possibly caused by the, Postmaster not
physically counting the cash when declaring it.
5.51.3 I Dates November 2007 - December 2007.
A Postmaster reported a discrepancy of £907.97 on the main SU which was believed to relate
to currency transactions: the currencies had been Remmed out, reversed, then re-Remmed
out.
Investigation by Fujitsu SSC indicated that the Postmaster was making incorrect cash
5.51.4 I What Happened I declarations, and POL NBSC were advised of this.
Analysis showed instances of cash declarations, followed by a Rem in or a transfer in that
would affect the cash figure followed by a further cash declaration for the same amount as the
first. This would create a discrepancy and suggests that the Postmaster was not actually
counting the cash when making the second declaration.
Fujitsu understands this to have been caused by incorrect cash counting, The original scenario
5.51.5 I Technical Analysis . . . .
on Legacy Horizon cannot be replicated. The system was working as designed.
5.51.6 I Testing Required? I No testing can be performed for this scenario.
5.51.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 59
POL00337673
POL00337673
®
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.52 23.3 Bureau de change — Issue 3
Item I Component Commentary
Horizon System .
5.52.1. Affected Legacy Horizon.
5.52.2 I Deseripdon There were a number of issues with the bureau rate board display of exchange rates
5.52.3 I Dates June 2010 - April 2011.
A software error led to a rate being rounded down within HNG-x so that the rate displayed at a
branch using HNG-X (9.269) was fractionally different from that displayed at a Horizon branch
(9.269). The same rate would have been applied by the two systems to any transactions carried
out, so would not have affected branch accounts. These were the details:
1) In Model Office the rate boards were not showing "trailing zeroes" (so 10.1
displayed instead of 10.100). This could not have affected branch accounts.
2) Rates showing on the Postmaster 's rate board were different from those on
Horizon. This was a known issue post-migration to HNG-X. The issue could not
have affected branch accounts.
3) Two issues raised by the Postmaster. Firstly, the rates on the rate board differed
from those on the counter; this was due to the rate boards having a 6-character
display limit, so that currencies for which the exchange rate was over 10 to £ 1
5524 I'WhatHappened were rounded up or down to fit into the available space. There was no fix for this,
it was a limitation of the rates board.
The second issue related to an actual difference in some rates between the rates board and
Horizon, beyond that explained by the rounding issue. This issue was intermittent and could be
resolved temporarily by forcibly refreshing the board from the counter. It was determined that
the issue had arisen following a data centre change (R4 Data Centre), after which the file feeds
from First Rate that supplied the spot rate and margin values for the day, started to arrive with
a gap of only five seconds or less between each other, instead of with a gap of around a
minute, as they had previously. It was suspected that the rates board was failing to refresh
from values as the files arrived in rapid succession. The fix was that First Rate started sending
the files a few minutes apart.
The issues in this Peak had an impact on branch accounts.
Check that rates displayed on Rates Boards exactly match the rates used to calculate the
5.52.5 I Technical Analysis I transactions in HNG-X, and also that all rates are displayed in a consistent format with regards
to decimal places and trailing zeros.
To validate that the Rate Board displays correct information and the appearance is exactly the
5.52.6 I Testing Required? "
same as the rates used by Horizon.
5.52.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 60
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.53 24 Wrong branch customer change displayed
Item Component Commentary
Horizon System .
o3-1, Affected Legacy Horizon.
When a quantity greater than 1 was entered for a Smartpost Transaction, the quantity was not
reset back to 1 when the user moved on to the settlement screen. This scenario could lead to
_ discrepancies due to subsequent items in the session being multiplied by whatever quantity
5.53.2 Description remained.
Although a fix was made, a further instance was then reported, leading to a second release of
the fix.
5.53.3 I Dates November to December 2005.
A Postmaster noticed that incorrect quantities appeared on the settlement screen after
entering stamps or postage labels on Smartpost.
This could result in subsequent items in the session being multiplied by that incorrect quantity
and so affect further items being sold, or the amount being tendered towards settlement.
On this first report of the error a Fujitsu engineer attended the branch on the same day and
changed the keyboard and screen which did not rectify the issue, so it was referred to Fujitsu
SSC as a suspected software issue. Fujitsu SSC spoke to the Postmaster to obtain further
5.53.4 I What Happened information and it was identified that the issue was likely to have started following changes
made to Smartpost which were implemented as part of a system release on 23 October 2005.
The issue was fixed however another instance of the same problem was reported by another
Postmaster in December 2005. It was realised that the fix had only been released to one group
of active branches while another group had not received it. The situation was explained to the
Postmaster by the Fujitsu SSC staff investigating. The fix was then released to the remainder of
branches on the next day. It was also known that non-polling branches would only obtain the
fix the day after they next ran Cleardesk overnight.
5.53.5 I Technical Analysis I Original scenario on Legacy Horizon (Riposte) cannot be replicated.
5.53.6 I Testing Required? I No testing can be performed for this scenario.
SSa.7 Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 61
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.54 25 Lyca Top Up
Item I Component Commentary
Horizon System . .
5.54.1. I attected Horizon Online.
Having entered a Lyca phone Top Up transaction at the counter, the counter was unable to
process the authorisation response returned from E-Pay, and the Postmaster would have to
5.54.2 I Description recover the transaction. If that recovery was done incorrectly, then a branch account
discrepancy would result, but if it was done correctly, then a discrepancy between POL and E-
Pay would result.
5.54.3 I Dates August 2010.
When entering a Lyca mobile phone Top Up transaction, the counter was unable to process the
authorisation response returned from E-Pay. This resulted in the on screen error message
“unable to connect to data centre", followed by the user being logged out.
This would lead to one of two discrepancies, depending on the actions carried out in the
branch following the above error:
1) If the user recovered the transaction and confirmed that it had been successful by
pressing 'Yes', a shortfall would be created for the branch to the value of the E-Top Up
transaction, as a successful transaction would have been recorded in the branch
accounts, indicating that money had changed hands. However, no money would have
5.54.4 I What Happened been taken from the customer.
2) If the user recovering the transaction confirmed that it had not been successful by
pressing 'No', then no discrepancy would be created for the branch, as. the
transaction would be recorded as 'zero value’ in the branch accounts, and a reversal
generated for the Top Up. Instead, it would create a mismatch between the data held
by POL and E-Pay. The discrepancy would have been flagged in the daily automated
NB102 report. Fujitsu would then issue a BIMS Incident report to POL, summarising
the particular occurrence and explaining the potential discrepancy to enable POL to
reconcile the position with the branch.
An issue was raised to document the fix and allow any further instances to be identified and
investigated.
This was determined that incorrect reference data was the cause of the error. This data has
5.54.5 I Technical Analysis I _ an ee .
since been replaced (multiple times) within Horizon, and can no longer be duplicated.
5.54.6 I Testing Required? I No testing can be performed for this scenario,
5.54.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 62
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.55 26.1 TPSC 250 Report - Issue 1
Item I Component Commentary
Horizon System .
S51, Affected Legacy Horizon
A counter code bug caused a failure to check that a prepaid amount was not greater than the
5.55.2 I Description aan ah ~
total amount, resulting in incorrect exceptions in reconciliation report (TPSC25).
5.55.3 I Dates 2005
This relates to an issue arising from Smartpost code failing to check that a prepaid amount is
not greater than the total amount and resulted ingost system reconciliation errors. These
false errors were then detected and reported.off By automated reconciliation reports.
5.55.4 I WhatHappened I The issue is limited to a reconciliation reporting issue and is separate to branch accounts. The
effect would have been to create unnecessary work for Fujitsu SSC investigating false
reconciliation issues.
5.55.5 I Technical Analysis I The original scenario on Legacy Horizon (Riposte) cannot be replicated.
5.55.6 I Testing Required? I No testing can be performed for this scenario.
5.55.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 63
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.56 26.2 TPSC 250 Report — Issue 2
Item I Component Commentary
Horizon System .
5.56.1. Affected Legacy Horizon
Five records were incorrectly written after recovery from a Data Centre communications issue
5.56.2 I Description resulting in incorrect exceptions being recorded in reconciliation reports (i.e. not real
exceptions in branches).
5.56.3 I Dates 2005
This was a related but separate bug to 26.1 TPSC 250 Report Issue 1 above that also caused
incorrect reconciliation exceptions to be reported, and, again, there was no impact on branch
accounts.
5.56.4 I What Happened _I The fault was found to be that a message with an incorrect date format could be written toa
database object. This occurred when the End of Day Agent failed to communicate with Riposte,
probably due to a temporary communications issue, causing the code to follow a recovery path
resulting in the incorrectly formed attribute.
5.56.5 I Technical Analysis I Original scenario on Legacy Horizon (Riposte) cannot be replicated.
5.56.6 I Testing Required? I No testing can be performed for this scenario.
5.56.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 64
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.57 26.3 TPSC 250 Report — Issue 3
Item I Component Commentary
Horizon System .
SS7.1. Affected Legacy Horizon
The TPS total for one branch was higher than the counter total due to the totals for day O and
5.57.2 I Description ‘ ‘I
day 1 being rolled into one.
5.57.3 I Dates 2005
The TPS Total in the Reconciliation TPSC250 report was higher than the Counter Total for a
single branch. It was confirmed! that the files/data sent to POL were unaffected by the issue,
and that this was another case of a false errordpearing on the report.
5.57.4 I WhatHappened I the error was that the TPS Total rolled the totals for day O and day 1 into one, meaning that
the Counter Total was correct for day 1, but didn't match the TPS Total, which was in itself also
correct.
The original scenario on Legacy Horizon cannot be replicated, Branch terminals no longer act in
this manner, as the TPS report was comparing to the figures stored within the counter - these
5.57.5 I Technical Analysis I : : .
figures are now in BRDB. The mechanisms are now very different - both the source of data and
the reporting have changed.
5.57.6 I Testing Required? I No testing can be performed for this scenario.
5.57.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 65
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.58 26.4 TPSC 250 Report — Issue 4
Item I Component Commentary
Horizon System .
5.58.1. Affected Legacy Horizon
Exceptions in a reconciliation report for a branch led to identification that an individual counter
5.58.2 I Description .
had errors and it was replaced.
5.58.3 I Dates 2005
The TPS Total in the TPSC250 report was showing as higher than the Counter Total for a single
5.58.4 I WhatHappened I D2"
me ™ Investigation showed that the error was caused by Riposte errors on counter 1 at the branch.
The branch counter was replaced.
5.58.5 I Technical Analysis I Original scenario on Legacy Horizon (Riposte) cannot be replicated.
5.58.6 I Testing Required? I No testing can be performed for this scenario.
5.58.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 66
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.59 26.5 TPSC 250 Report — Issue 5
Item I Component Commentary
Horizon System .
$59.1. Affected Legacy Horizon
A particular Smartpost transaction type produced intermittent exceptions on reconciliation
5.59.2 I Description
reports.
5.59.3 I Dates 2008 - 2010.
Asingle branch showed that the TPS Total and Counter Total Values for the Number and
Absolute Quality columns were the same, but with a difference in the Absolute Value, which is
greater than the TPS value. This was a mismatch between the TPS Absolute Value and Counter
Absolute Values.
There was a problem with Bulk Mails was that the Credit/Debit tags were written as double
that of the Sale Value. This does not cause an impact upon the branch as these values are only
5.59.4 I What Happened _ I used in the calculation of the reconciliation report at the data centre and did not affect the
information sent to POL or the branch accounts.
The incidents had occurred where 1) the session did not net to zero, in which case an
incomplete summaries and receipt and payments mismatch would result, or 2) in which the
transaction message was not written but the balancing message was written.
This was then picked up in the datacentre counter measures and would cause a receipts and
Payments mismatch at the branch.
5.59.5 I Technical Analysis I The original scenarios on Legacy Horizon (Riposte) cannot be replicated.
5.59.6 I Testing Required? I No testing can be performed for this scenario.
5.59.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 67
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2021
5.60 27 TPS
Item I Component Commentary
Horizon System .
5.60.1. Affected Legacy Horizon
Smartpost wrote slightly corrupt transactions which led to incorrect exceptions reporting but
5.60.2. I Description . ~
did not impact branch accounts.
5.60.3 I Dates Between 2006 and 2010.
A Peak was opened following the detection of a Smartpost transaction in which the Credit
attribute doubled against the sale value. The attribute concerned was used to calculate the
‘EPOSSDailyRecon' absolute values, which in turn triggered the TPSC250/257 exceptions in the
case of a mismatch with the Host generated Totals. A check of the messagestore for non-zero
sessions found none, so it was concluded that there was no balancing problem for the branch
concerned.
AKEL was raised as a result. This bug affected Smartpost transactions which were either
5.60.4 I What Happened I missing the grammar attribute and / or had a corrupted grammar attribute. The grammar
attribute is used to calculate the value for the reconciliation reporting, meaning that as the
attribute was either missing or corrupted then reconciliation reporting errors were produced.
Of the 40 Peaks identified that reference the KEL, the majority (36) had Sale Values that netted
to zero and therefore, required no reconciliation. The remaining four required corrections for
small amounts to be made to the ‘TPS_POL_FS_Summaries_Incomp’ table, which were carried
out under OCRs.
5.60.5 I Technical Analysis I Original scenario on Legacy Horizon (Riposte) cannot be replicated.
5.60.6 I Testing Required? I No testing can be performed for this scenario.
5.60.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 68
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.61 28 Drop & Go
Item I Component Commentary
Horizon System . .
5.61.1. I attected Horizon Online.
i A Drop & Go transaction failed to credit the customer's card, so was retried, resulting in the
5.61.2. I Description . ° , :
branch being debited twice, hence creating a shortfall.
5.61.3 I Dates June 2017, August 2018.
A clerk initiated a Drop and Go transaction for £100 which failed due to timeouts, but then a
success was displayed, so the clerk settled the transaction. The customer checked their balance
and stated that the top up had not been processed. The clerk then performed another Drop
and Go transaction that was successful.
5.61.4 I What Happened _ I This resulted in a £100 shortfall for the branch as Horizon recorded the top-up twice.
Reconciliation between the Horizon feed and the Accenture Common Digital Platform (COP)
system identified that only one top-up had been received by Accenture COP, but two top-ups
were present in the Horizon Batch Feed. The second Horizon transaction matched the COP
transaction, confirming the problem was with the first transaction.
There have been changes to the process of Drop & Go since 2018, the online interaction has
5.61.5 I Technical Analysis
been changed also.
Ifa Top Up transaction behaves correctly in the instance of a network time out, where the
5.61.6 I Testing Required? I payment does not reach the CDP, and the customer is not charged for the transaction, then
this item has been correctly resolved.
5.61.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 69
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.62 29.1 Network Banking — Issue 1
Item I Component Commentary
Horizon System .
5.62.1. Affected Legacy Horizon.
An intermittent fault, most likely attributed to the line provided by BT and Energis, caused a
5.62.2 I Description transaction to not complete. A shortfall in the branch account was caused by the Postmaster
handing over the money despite failure.
5.62.3 I Dates October - November 2004.
A Postmaster reported that their ISDN line (operated by Energis and BT) was down and had
been having connectivity issues for two weeks. The Postmaster also reported issues with two
customers' pensions transactions for £90 and £50, in which the transactions had been
declined. The two customers had returned to the branch the following day stating that the
money had been taken from their accounts, despite the transactions having been declined the
clay before.
Fujitsu SSC was able to make a voice call on the line, and also undertook analysis of the
network banking messages recorded in the messagestore.
The root cause was identified as being an intermittent fault with the BT ISDN line.
5.62.4 I What Happened
Further checking with the Postmaster confirmed that one of the transactions (£90) had been
correctly refunded to the customer, the other transaction (£50) was refunded but there was a
delay in it appearing in the customer's account, which resulted in them complaining to the
Postmaster . As a result, the Postmaster handed the customer £50 which lead to a shortfall for
the branch.
The original scenario on Legacy Horizon cannot be replicated. It is recognised that
5.62.5 I Technical Analysis I communications failures (network issues) can still occur today however this is a known risk of
distributed locations of service. This individual issue was a one-off and cannot be duplicated.
5.62.6 I Testing Required? I No testing can be performed for this scenario.
5.62.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 70
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2027
5.63 29.2 Network Banking — Issue 2
Item I Component Commentary
Horizon System .
5.63.1. Affected Legacy Horizon.
Intermittent breaks in OLS (Online Services) due to, problems with a BT line. Although this issue
5.63.2 I Description meant that no Network Banking activities could be carried out while the service was down, no
specific transactions are referred to in the related Peak.
5.63.3 I Dates January 2010.
A Postmaster reported a temporary communications issue, potentially caused by adverse
5.63.4 I What Happened I weather. The issue was investigated by Fujitsu, but, after a short period, the communications
were restored, and the Postmaster agreed the Incident could be closed.
The original scenario on Legacy Horizon cannot be replicated. It is recognised that
5.63.5 I Technical Analysis I communications failures (network issues) can still occur today however this is a known risk of
distributed locations of service. This individual issue was a one-off and cannot be duplicated.
5.63.6 I Testing Required? I No testing can be performed for this scenario.
5.63.7 I Status READY FOR SIGN OFF
STRICTLY CONFIDENTIAL [Publish Date] 71
POL00337673
POL00337673
©
Historic KELS Determination and Closure v0.5 Draft 28th June 2021
6 Appendix
6.1 Fujitsu Test Closure Report
N
a
TSTSOTREP4269.D0
x
6.2 POL Test Closure Report
POL_Test Closure
Report - Historical KEI
STRICTLY CONFIDENTIAL [Publish Date] 72