FUJ00087274
FUJ00087274
GIJ Response to Information Requests from Jason Coyne
Ref:
gij response to information requests from jason coyne.docx
Author: Gareth I Jenkins
Date:
1.
2.
2.1
15/06/2018 07:15:00
Management Summary
Jason Coyne, an IT expert working for various postmasters, has asked Fujitsu to
respond to a number of questions regarding the operation of Horizon and Horizon
Online.
This note documents the questions that have been allocated to Fujitsu from document
180516RF11935 First Request for Directions 01-00.pdf together with the responses
already provided by Jon Hulme (and others).
I have added the text of the original question (from Jason’s document) to aid
readability and also added my comments / thoughts on the answer given and any
further thoughts I have.
The Questions, Answers and Comments
The following subsections go through each question that has been posed to Fujitsu. In
each case the question (as worded in Jason’s document) is in italics, followed by Jon
Hulme’s response in purple text. I have then added my comments in red text.
REI 1.4 (POL-0032932.doc is attached
Regarding POL-0032932.doc, what is the purpose of setting an NB102 exception to
F99 by FJ?
I POL-0032932.doe is CS/SPE/011 - Network Banking End To End Reconciliation Reporting I
a) How often has this occurred?
b) What is the cause of an ‘Uncleared Transaction Corruptions’ and how often
do these occur?
This is about the purpose of setting exception F99 in the NB102 rules concerning
Network Banking End to End Reconciliation
This applies to both Horizon and Horizon Online.
Whenever any incident involving a reconciliation exception in Network Banking has
been fully processed, then the transaction needs to be set to F99 to indicate that
gards to ‘How often has this occurred’ — the category of NB102 is too wide a
'y and we suggest this question is clarified as to what specific transaction status
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\users\gareth\onedrive\documents\gij\work\ccre query\duplicates in horizon audit data.docx
Page I of S
2.2
2.3
2.4
FUJ00087274
FUJ00087274
type. We currently F99 10,000+ transactions per week across all NB102 associated
reports (DCP and NBS).
Uncleared Transaction Corruptions would probably be due to bugs and so are unlikely
to occur in the Live system. The Security team may be able to provide details of how
often (if at all) this subsection of the report is produced. I can’t recall seeing one in
Live. oe ea ee ed
RFIL.7 a. (POL-0032864.doc is attached);
In relation to POL-0032864.doc “Data Errors / Not Data Errors”:
POL-0032864.doc is CS/SER/017 - Data Errors & Not Data Errors — Contractual
Definitions
a) Please describe what “work-arounds” have previously been agreed between
PO and FJ in accordance with page 6 where “...inaccuracy or error was not
capable of being corrected by the User before irrevocable commitment of the
cash account in question...”
This is about workarounds for the Cash Account error situations in old Horizon.
This applies to the Horizon system prior to the changes introduced by the Impact
programme in 2005 or 2006. I was not involved in the detailed reconciliation of the
counter until we made the changes to Branch Trading Statements as part of Impact, so
don’t think I can help with this.
RFIL1.8;
Please describe in reference to the above document at page 20 what the effects are if
the data is not transmitted within five working days?
This is about “the effects are if the data is not transmitted within five working days (in
old Horizon).
We have no knowledge of this — perhaps ask Gareth Jenkins/SSC?
Again, before my time with the counter, so may be able to get something from SSC. I
assume this relates to the timings on the old Post Office Ltd accounting system CBDB
and the timescale for getting changes into it before it passed data onto other backend
systems.
REI 4.2 (POL-0032913 is attached);
In relation to POL-0032913, can more information be provided on the “backlog of
discrepancies” held by FJ?
POL-0032913 is an informal note entitled SSK Reconciliation
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\users\gareth\onedrive\documents\gij\work\ccre query\duplicates in horizon audit data.docx
Page 2 of 5
25
FU.
This is regarding 1.15, which Steve Parker has responded to (although we don’t think
Steve’s response matches the question being asked).
I’ve not seen Steve Parker’s response in the emails sent to me.
I seem to remember that there were a lot of discrepancies identified in NB102 reports
relating to kiosk transactions and there was an issue that because they were not being
cleared down (ie set to state F99), then it was difficult to distinguish new discrepancies
from old ones. This looks like the notes from a meeting to put in place a better
process for clearing down the error logs
SSC and the Fujitsu Security team (who were also responsible for reconciliation)
would have been involved in running this process together with the FSC team in POL.
I was probably involved in the discussions, but I can’t remember anything further at
this point.
RFI 4.3 (but not the "how many transactions have been repaired" part as this is
out of scope):
2.6
Please describe what situation led to the process outlined in POL-0032939.doc (TPS
~— EPOSS Reconciliation TIP Transaction Repair) and how many transactions have
been repaired?
POL-0032939.doc is not in the email stream I have been sent
This is regarding 1.16, which Steve Parker has responded to, although Steve says he
hasn’t seen the document which referred to, which you have attached.
I can’t add to this without seeing the document. Specifically does this refer to Horizon
or Horizon Online? There were cases where some transactions harvested from Riposte
were missing mandatory attributes — particularly for Mails based transactions, and
there was a process for manually correcting these transactions before they were passed
to Post Office Ltd. This would have no impact on the Branch accounts and no
changes were made to Branch Transactions’ — just completing information needed by
the back end systems.
RFI 5.2 (Pete — when we spoke previously you suggested this was a question for
POL but given that it relates to reconciliation of data within Horizon I think it is one for
Torstein);
2.7
Please describe what the process is following the discovery of a discrepancy between
the two sources?
This is regarding 1.18. We have no knowledge of this — perhaps ask SSC.
It depends on the discrepancy and what the sources are. I think we need a more
specific question.
RFI 6.3 (POL-0032915 is attached);
In relation to POL-0032915, are any technical bridge or service bridge meeting
minutes (or similar documentation) available (page 31)?
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\users\gareth\onedrive\documents\gij\work\ccre query\duplicates in horizon audit data.docx
Page 3 of 5
FUJ00087274
}J00087274
2.8
2.9
FUJ00087274
FUJ00087274
POL-0032915 is an unnumbered document - Description of Fujitsu’s System of IT
Infrastructure Services supporting Post Office Limited’s POLSAP and HNG-X applications
This is regarding 1.23 asking for records of bridge meeting minutes. We have no
knowledge of this — perhaps ask SSC
I have attended some Tech Bridge calls, but I don’t know what records are kept. This
is one for Steve Bansal.
RFI 6.4;
Regarding Correcting Accounts for lost_ Discrepancies - G Jenkins.pdf, how was it
ultimately decided if/how FJ should be “correcting the data”?
a) “Of the cases so far identified there is one for £30,611.16, one for
£4,826.00 and the rest are all less than £350” - are these losses or gains?
b) How many FJ users are able to adjust the Opening Figures and BTS data?
©) Is there an audit trail of a decision being made by POL to ‘write off the “lost”
discrepancy’ and adjusting of the Discrepancy account to align the decision in
POL SAP?
G Jenkins. pdf is a document I was sent recently and have ]
This is regarding 1.24 asking detailed questions about “G Jenkins.pdf’. We have no
knowledge of this — perhaps ask Gareth Jenkins.
It was agreed that the discrepancies would be fixed in POL SAP by FSC. There was a
document DOC_38239623(1)_Documents relating to disappearing
discrepancies.pdf which was the merge of records from a Conf call and a note by
myself. In the first part on page 3 there were 3 alternative solutions proposed.
Solution 2 was actually adopted (but that was not noted in the minutes and was
probably decided separately). No changes were made by Fujitsu to any counter data.
RFI 6.5 and RFI6.5(a) (POL-0032936.doc);
With regards to POL-0032936.doc, what is the definition of a “red event” and what
were the consequences of a red event being raised silently with no direct feedback to
the operator?
a) Further, how were these ‘silent’ red events identified?
POL-0032936.doe is DEV/APP/SPE/1821- Audit Client Error Handling Improvements ]
This is regarding 1.25.
A red event is a Window Event Log item with Error status.
Jason is asking more about silent red events.
We suggest Gerald responds to this as it concerns questions on a document he
authored.
I think Gerald has covered this.
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\users\gareth\onedrive\documents\gij\work\ccre query\duplicates in horizon audit data.docx
Page 4 of S
FUJ00087274
FUJ00087274
2.10 RFI 8.3 (POL-0032862.doc is attached); and
In relation to POL-0032862.doc, what is the nature of the data error to be repaired as
per section 3.4.3?
a) What information is contained within in a “Business Incident”?
b) Is there a log of all “Business Incidents” and “System Incidents”?
POL-0032862.doc is CS/PRO/111- TPS Reconciliation & Incident Management
This is regarding 1.35
This concerns old Horizon TPS Reconciliation and Incident Management.
We have no knowledge of this — perhaps ask Service.
This should be addressed by the security team as the Incident team were merged into
the security team around the time of the change form Horizon to Horizon Online. I
think this is probably the same process as described in section 2.5 above.
2.11 RFI 9.3 c.
With regards to POL-0032836.doc ‘EPOSS End-to-end Reconciliation Process For
Release NR2 - Incident Management & Resolution’:
c) Also please provide a description of the class of documents (if any) which
record that data has been modified (and/or transactions inserted) in Horizon
in circumstances that may impact a branch’s account or transactional
information.
I POL-0032836.doe is not in the email stream I have been sent ]
This is regarding 1.40 in old Horizon.
We have no knowledge of this — perhaps ask SSC
I assume that this relates to the Riposte based Horizon. I am aware of the process, but
I’m not sure how the audit trail operated. I assume it was done by BSU raising a Peak
which was sent to SSC to resolve and the Peak would then be closed. Looking at old
Peaks raised by BSU might help?
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\users\gareth\onedrive\documents\gij\work\cerc query\duplicates in horizon audit data.docx
Page 5 of 5