7,8,9
10, 11
12
13, 14, 15
16, 17
FUJ00160194
FUJ00160194
WOMBLE
BOND
DICKINSON
RESPONSE TO RICHARD ROLL (TO BE TURNED INTO A STATEMENT BY STEVE PARKER)
1.
2.
References to paragraph numbers are to paragraphs of Mr Roll' statement.
I worked with Mr Roll while he was employed by Fujitsu_in the Software Support Centre (SSC).-
Although I did not have the formal title, I acted as team leader.-
I found Mr Roll to be a conscientious worker and provided him with a reference for a position that
he applied for after I ving Fujitsu. As described below, he was not what I would describe as a
technical person and ‘he was mainly tasked with undertaking standard work arounds: e.g.
Advising a PM to reboot when a counter was non-polling (not communicating with the centre),
changing an outlets end of day state to ensure harvesting takes place, changing outlet
configuration to facilitate change in number of counters.
[ 1.
As Mr Roll was employed between 2001 and 2004 his references to Horizon are to the original
Horizon systet ;ometimes referred to as Legacy Horizon) as opposed to Horizon Online/HNG-
X. When deal with matters in this statement I am describing the position between 2001 and
2004 unless otherwise stated.
[I have reviewed paragraphs bexfor the witness statement provided by my colleague Torstein
Godeseth which describe the core audit process in Legacy Horizon and I confirm that they are
accurate to the best of my knowledge and belief.] [TBC]
Structure of Fujitsu's Support teams for the Post Office Account
6.
6.1
There were four lines of support for Horizon while Mr Roll was employed by Fujitsu_and this is
Still the case in the current Horizon support structure, albeit names have changed and some
responsibilities have moved around teams. A multi-level support model is common within the
industry, as you move up through the levels of support the skillset required changes as does the
cost of the staff providing the service. To provide efficient support your objective is for an
incident to be resolved by the earliest level possible. The following points define the names.
responsibilities and qualities of the Horizon support lines at the time to the best of my
recollection. There is often overlap of skills between adjacent lines of support. While a team may
be responsible for a particular level of support, staff within that team often have sits which
allow them to perform a role outside the team’s level. [is-thi
iste f-del 21s the setup industry standard}
1* line: the Horizon system utilised a joint 1* line helpdesk as the first point of contact for issues.
6.1.1 The National Business Support Centre (NBSC) being a Post Office staffed helpdesk
tasked with resolving business issues.
6.1.2 The Horizon Service Desk_(HSD), a Fujitsu_staffed help desk a—helpdesk—that
branches may contact with issues relating to the Horizon_application or the hardware
provided in branch by Fujitsu to run the Horizon application — The helpdesk dealtals
with straightforward issues such as password issuesresets, BAe hardware replacement
and engineer scheduling. The 1% line helpdesk refers other issues to the 2% line
support function. TE: Names have changed over the years, HSH (Horizon System
Helpdesk) and HIT (Horizon incident team) have also been used but the combined
functions remained the same as HSD described aboveteam;
6.1.3 Communications Management Team (CMT). A 1“ line team specifically focused on
communication incidents.
AC_152319334_1 1
FUJ00160194
FUJ00160194
Page 1 Comments
PS1
PS2
SH3
PS4
GJ5
GJ6
GJ7
GJ8
Ps9
“personal reference”. FJ do not allow staff to produce references on behalf of the
company.
Parker, Steve, 16/10/2018 02:54 PM
Change of wording: As described below, he did not undertake a lot of detailed
diagnosis of new issues. His skills were mainly in the accurate application of known
work rounds to configuration and storage issues resulting from routine outlet change
activities (reducing / increasing numbers of counter at outlet .....).
Parker, Steve, 16/10/2018 02:55 PM
In order to justify the conclusion that Roll was not technical (which is important) we
need to be specific about what he did, where this fitted in to the overall team and why
others were far more engaged in technical work than him. Are we trying to make any
further point here i.e. that as a result of his role he would not have understood aspects
on which he is giving evidence?
Simon Henderson, 15/10/2018 09:39 AM
Analysis of his incident updates show that he was working in the SSC from just before
March 2001 to Sept 2004. I say “just before” because prior to answering incidents
himself he would have been shadowing an experienced diagnostician but his name
would not have been applied to the work being completed.
Parker, Steve, 16/10/2018 02:59 PM
Missing “I”.
Gareth Jenkins, 15/10/2018 04:28 PM
tbs
Gareth Jenkins, 15/10/2018 04:29 PM
Probably sensible to also refer to POL’s NBSC and how that fitted in with Fujitsu’s
HSD
Covered at point 13 below?
Gareth Jenkins, 15/10/2018 04:30 PM
Presumably it is?
Gareth Jenkins, 15/10/2018 04:29 PM
I do not have numbers for staff in SSC 2001 — 2004. Best I can do is end 2009 when
there were 25 SSC staff. An estimate of 25-30 is reasonable.
Ist line FJ was around 80-90. We don’t have people (Sandie Bothick, one of the
“longest servers” I know on the helpdesk, only joined in 2009) who can give better
figures.
NBSC: No idea. Post Office may know.
Parker, Steve, 17/10/2018 07:50 AM
FUJ00160194
FUJ00160194
Page 1 Comments (Continued)
GJ10 With Riposte there was no capability of password resets. There was a one-shot
password capability for “global” accounts which allowed a SPMR to log on with the
privilege to allow them to reset a password locally.
Was this HSD or NBSC?
Gareth Jenkins, 15/10/2018 04:31 PM
PS11 HSD
Parker, Steve, 17/10/2018 12:01 PM
PS12 Deliberate use of “function” not team. The second line function was spread over
HSD, SMC and SSC (Software Support Centre). SSC also fulfil a third line function.
Parker, Steve, 16/10/2018 03:48 PM
FUJ00160194
FUJ00160194
19 6.1.4 Ast line support was also responsible for monitoring the live estate and taking
corrective actions defined in knowledge documents, based on the content or frequency
of those events. This role was fulfilled by two units:
20 System Management Centre (SMC): Data centre events
21 Counter Eventing Team (CET): Post Office counter events
1) 2" line: search knowledge articles and apply simple, well-defined work-arounds (often on the
phone) such as guiding branch staff to return to the Horizon home screen if they get stuck in part
22 of the system. There was no single 2nd line support team for Horizon. 2" line functions were
fulfilled by ‘1st line or 3rd line teams. 2 line support of the Horizon application was executed by
senior members of the HSD, pets ner junior members of the SSC. fseomeone-mentioned-
itoring syst pand-on that please}:
23. I6.2 3° line: 3rd line support staff apply analytical skills to the symptoms and evidence gathered by
the 1st and 2nd line functions and undertakes in-depth investigation into incidents. They have
detailed knowledge of the application based on documentation and source code inspection. 3°
line staff design, test and document work rounds for previous levels of support. They undertake
complex (which may require the generation of special tooling) configuration and data fixes.
Design, write and document new support tools. Undertake source code examination, complex
diagnosis and documentation (including method to recreate fault) of new application problems
before sending them to the 4th line support group for root cause software fix; and
seat erie eae ean ep roeicrt cereale
'g- vy
a
.
hile fwhen 2}. ena branch ired_assist: t
24, 25, 26 I 6.3 4" line: syster-development of and-software fixes. Have intimate knowledge of narrow areas of
the system and are ultimately responsible for the production of permanent fixes to repair the root
cause of an incident or problem in the live application. 4" line support staff have knowledge of
one of more computer languages which they utilise to amend source code to fix problem in the
live application code. There is often overlap between 4" line and Developers, who add new
features into the application. f we-d ibe the-quatifications required to-bi be
26 I 7. The 3” line support team is only ever engaged when there has been a problem that all previous
27 support functions (1st line, 2 line) were unable to resolve. Where the 1" line helpdesk might
receive 13000-14000 calls per month from Post Masters the majority (e.g. 95%) will be answered
by that helpdesk. Input tothe, SSC was approx. 1000 calls per month. Output from SSC to 4".
28 line, approx 20 per month’ NOTE: [Insert section re metrics around various lines of support.
1st line — 90-95% of issues; 5-10% to 2nd line and less to 3rd line. Metric = 3% of input to
3rd line should go to 4th line (development). A mature system now, but still worth saying
that you have to bear this thing in mind. Need figures from Sandy Borthwick (HSD
days). PN/DI to chase up.]
Mr Roll's role
29 I 8. Mr Roll was a member of the Software Support Centre (SSC) team which is described as the 3°
line support group. Functionally the SSC provided both 2%¢ and 3 line support for the Horizon
30 application (-which-pri idesthe-34i PPX isee previous comments, there-can-be-
31 soeme-overlap between aa four lines of support)-and SSC-does-provide some 2"ine support).
9. As with any mix of people, there are various levels of talent within SSC. Mr Roll was primary
utilised in Operational Business Change (OBC), which involved supporting the engineers who
were opening and closing branches and also increasing and decreasing the number of counters
in branches and correcting the application environment after engineers replaceding failed
counter hardware. As part of that role he may have spoken to Postmasters from time to time.
[Can we describe the sorts of things he would not have routinely seen as part of his role?
32,33
AC_152319334_1 2
FUJ00160194
FUJ00160194
Page 2 Comments
GJ13
GJ14
PS15
SH16
This was probably me. SMC should monitor unusual events from all Live systems
(including branches) as they went through the event management system and raise calls
in unexpected events (or as defined by KELs)
Gareth Jenkins, 15/10/2018 04:33 PM
4th line was normally the original development team who would do this alongside
developing new code.
Gareth Jenkins, 15/10/2018 04:35 PM
Still not accurate, my recollection. Sandie Bothick has provided HSD stats from Dec
2008 - Jan 2009 which support the 13000-14000 figure BUT
a) this does not include the NBSC (POL)
b) By Jan 2009 Horizon was mature and HNG-X was being developed
(introduced 2010)
Person who can drag out the SSC stats is on leave. Need to either tie down these
figures from the incident system OR use current figures and explain that they only
indicative as the current system is mature.
Parker, Steve, 17/10/2018 10:03 AM
Worth making the point somewhere that there is a degree of overlap between the
various lines of support i.e. not clear cut distinctions
Simon Henderson, 15/10/2018 10:04 AM
FUJ00160194
FUJ00160194
Is there a possibility that his witness statement covers things paurh he would not have
had first-hand knowledge of? If so, please provide examples.]
10. Mr Roll was not involved in the provision of 4" line support. Some members of the 3” line
support group (but not Mr Roll) identify the need for software fixes and pass this on to the 4" line
team for a code fix to be written. Such a code fix would not be written by anyone in the 3” line
team.
Branch discrepancies
11. Mr Roll states that "software issues" which "could, and did, cause financial discrepancies at
branch level, including "shortfalls" being incorrectly shown on the Horizon system" were
"routinely" encountered (paragraph 10). It is true to say that as with any system, software issues
in Horizon may cause the illusion of a discrepancy in a branch's accounts from time to time.
However, it does not happen "routinely". [can we give an anecdotal estimate of how regularly
such issues arise?] Further, in the vast majority of cases such,a! occurrence would cause 5a)
receipts and payments mismatch that would be flagged [by who's and investigated [by whoat
[Why most bugs? What type of bug would not cause a receipts and payments mismatch?
How would they be identified?]
12. [Explain KELs and Peaks/how errors are identified and spotted? Note GJ's comment that
it is "quite difficult" to check how many issues caused discrepancies in Old Horizon, but
FJ is "tracking things better in new Horizon" (e.g. the three known bugs)]
13. Post Office operates its own 1* line helpline for branches called the National Business Support
Centre (NBSC). If a branch requires assistance to attempt to determine the cause of a
discrepancy they may contact NBSC. However, Horizon records the data that is entered into it
by branch staff and that may not reflect what actually happened in the branch. For example, a
user may enter a deposit of £100 into a customer's bank account on Horizon but rather than
taking £100 from the customer, they may make a mistake and give the customer £100 as if it
had been a withdrawal. Therefore, NBSC could not always help branches to identify the cause
of a discrepancy and they would sometimes ask SSC to assist. One of the reasons for this is
that SSC has access to transaction data whereas the NBSC does not. Mr Roll' statement that
"[ijf an error was referred to us then it was extremely unlikely to be due to a mistake made by a
posmmeste™ is simply not correct. gee ce tlie
d-to-be-h: bi th 4d
14. Mr Roll suggests that he would investigate financial discrepancies that had arisen in branches by
"work[ing] sequentially through all transactions over the relevant period, and also work[ing]
through thousands of lines of computer coding" (paragraph 7). To the best of my recollection Mr
Roll would not have worked through thousands of lines of computer coding to investigate a
siajrepancy I ina branch: wine ae has access AD vie ase ic (VB) code Iwhatis-this-code-
e ? Pit was rarely used
hy-RR Id-not-h: ded-tolook-at
d-for?-C:
[wh:
t pl
WOR re would follow work around processes designed by other people and was never a
detail person [ which would not require him to review VB code -
15. Mr Roll states that "[sJoftware programs were written by us to strip-out irrelevant data, to enable
34 us to more easily locate the error." I am aware of two programmes-support tools (AKA software
programs) that were written while Mr Roll was employed by Fujitsu:-
35,36 I 15.1 the Smiley support toolpregram written by my colleague John Simpkins. This tool
37, 38 whichamalgamates information from various sources (¢.g. databases) into a single view
pertinent to a particular support task and provides a unified interface to run various tools to
achieve a single support outcome [deseribe-whatit-did]; and
39, 40,41 I 15.2 _ the finsert name} programmme (Can't remember the name) written by my colleague Richard
42 Coleman to extract messages from the correspondence server to local text files for examination._
‘AC_152319334_1 3
FUJ00160194
FUJ00160194
Page 3 Comments
PS17
GJ18
GJ19
PS20
GJ21
GJ22
PS23
PS24
PS25
His statement suggests that he undertook detailed analysis and code examination. Not
correct, if he was involved in this way once I would be surprised. Yes, that is one of
the expectations of a 3rd line function, yes some of his colleagues would be doing this
work, it just wasn’t Richard doing it.
Best way to dispute this is by analysis of the incidents Richard answered. In progress.
Parker, Steve, 17/10/2018 02:14 PM
By the branch system as part of the balancing process (and also generate alerts that
would be picked up by SMC)
Gareth Jenkins, 15/10/2018 04:37 PM
Initially by the branch, but there wasn’t much they could do — and the SMC should
then raise a call and pass it to SSC to investigate it properly.
Gareth Jenkins, 15/10/2018 04:38 PM
We should be able to get this data from the incident management system (Peak).
Analysis would have to be driven by the code (final response code) allocated by the
person who finalised the incident, which is subjective. Within these constraints, yes
possible.
Parker, Steve, 17/10/2018 03:52 PM
The counter code was written in VB
Gareth Jenkins, 15/10/2018 04:40 PM
Data Centre code would be in other languages — primarily C and Pro SQL and I
assume SSC had access to all of this if required. However it was primarily 4th line that
looked at code fixes.
Gareth Jenkins, 15/10/2018 04:41 PM
Yes, SSC have access to all source code
Parker, Steve, 17/10/2018 03:47 PM
Source code access used to confirm exactly how the application would process a given
input and what the outputs would be. Used when investigating specific issues and
general education on how the system works.
RR was not working at a level where this would be required. The majority of his work
was the application of known work rounds / configuration changes.
Parker, Steve, 17/10/2018 03:48 PM
Yes.
Parker, Steve, 17/10/2018 03:51 PM
42
43
44
45, 46, 47
48
49 I
50
51, 52
54 I
16.
17.
18.
FUJ00160194
FUJ00160194
A predecessor to Smiley whose functions were eventually subsumed into the Smiley support.
tool.
[What is Mr-Roll-talki i Zofhis-state t-and-how-did-thi
peut .
programmes help-to spot them?]
I do not accept that SSC "regularly" identified issues with the computer coding. As with any
application, there were some coding errors in Horizon. A lot of the stuff we saw was [misuse of
the system, actions to ensure that dataset system was using was complete][please expand on
this].
Mr Roll states that if SSC was "unable to find the cause of the discrepancy then this was
reported up the chain and it was assumed that the postmaster was to blame" (paragraph 10).
That is not my experience: It is a simple truth of support that the majority of issues reported in a
system are attributable to user action or user misunderstanding of system functionality. Hence.
anybody working in a support environment analysing a new issue would examine the possibilities
of user error as a first hypothesis but any final conclusion is only generated based on the
evidence. Where the evidence does not support a conclusion the SSC feeds the existent factual
data back to Post Office and might say something along the lines of "all indications are that the
branch has made a mistake" if thereis-no-other-explanation,but SSC neither does-notattributes
"blame" or agrees the final conclusion with the Post Master. -
SSC between 2001 - 2004
19.
20.
21.
22.
23.
I agree with Mr Roll's recollection that there were around 30 individuals working on the 6" floor in
Bracknell at any one time during this period. [H part of SSC? Hi is the 30
split? However I strongly disagree that much of the work being carried out could be described
“as "fire fighting" coding problems in the Horizon system." There would be times when SSC.
would be firefighting when, for example, a data centre went down. However, as described
above, SSC would primarily provide 3" line support including {writing the knowledge articles
used by the 2" line support team, carrying out fixes in relation to configuration type issues (as
opposed to software configuration fixes, an example being where the system crashes while
[whenr?] balancing a stock unit and the branch required assistance to unlock the stock unitit) and
examining some code.
There were Service Level Agreements for issues such as stuck transactions (Fujitsu had 10 days
to retrieve transactions that had got stuck in a counter). I do not understand what Mr Rolls
means when he says that "any discrepancy in the post office accounts had to be resolved
speedily” (paragraph 12). [Is-thi tordo you ki Rath ? I
While it is correct that there was a limited number of opportunities to release software updates
and it could be six weeks before a fix could be released, but in the vast majority of cases it did
not take six weeks to do this. I do not understand what Mr Rolls means when he suggests that a
bug could reappear several weeks after a coding fix had been released due to software issues
(paragraph 14), although I am aware of cases where a fix regressed [how many times has this
happened?].
[What rti a (4) softy + (2) hard: yrs
prop Hh +42} 24
Remote access
24.
25.
Mr Roll claims that "[djuring the course of resolving the software issues, we would frequently
access a Post Office counter IT system remotely" (paragraph 15). By remotely I assume that Mr
Roll means accessing Post Office counter IT systems while not in a branch.
The first point to note here is that a level of such access was required in Legacy Horizon
because it was a distributed system._The counter hard disk was used to store application
‘AC_152319334_1 4
FUJ00160194
FUJ00160194
Page 4 Comments
PS26 Need to break down the para:
He is referring to the investigation of discrepancies by the SSC. A number of points to
be made here:
1) Discrepancies, general. Discrepancies impact all retail systems, rarely will the
contents of the till match up to the entries made onto them by the person
serving.
2) Discrepancies, value £5000. Would be unusual in a system where your single
item cost is low, e.g. packet of Polo’s 40p. In a system where you are also
dealing with high value items (e.g. commercial volumes of tax disks), £5000
would not be unusual.
3) Discrepancies are normally a business issue, not a software issue, and hence
the NBSC would deal with them not 3rd line support.
4) Inasmall number of cases the NBSC would be unable to resolve a
discrepancy with the Post Master. That could result in a “well I can’t find the
problem so it must be software” attitude resulting in the incident coming to the
SSC. The SSC generally had better access to the data and support tools than
the NBSC (hence “Software programs were written by us to strip out
irrelevant data”) to examine the sequence / value of transactions made in a
branch. The result of our investigation was generally an explanation of which
legitimate transactions, made by the Post Master (sometimes in error) caused
the discrepancy.
5) In very rare circumstances a discrepancy could be caused by a software issue.
In this case it might be necessary to “work through thousands of lines of
computer coding”, however this would be a 4th line function not 3rd line.
6) When the root cause is identified the support teams would be able to identify
the outlets impacted and advise on a corrective action or even make that
corrective action in co-operation with the Post Master.
Parker, Steve, 17/10/2018 02:34 PM
PS27 25-30 is a reasonable estimate of SSC staff during Richard’s employment.
Parker, Steve, 17/10/2018 12:31 PM
PS28 The system carries out self consistency checks. Failure of these checks results in a
report of a “receipts and payments mismatch” and could create the illusion of a
discrepancy. Results in a support follow up and reconciliation of issue. Spreadsheet
available to document.
Parker, Steve, 17/10/2018 03:16 PM
PS29 There is a process run by the Management Support Unit (MSU) which involves that
examination of various system reporting and may result in BIMS (Business Incident
Management Service) entries that go to Post Office. An incident may also be raised by
MSU with the SSC to provide support to the MSU in resolution of the BIMS. These
subject to strict SLAs.
FUJ00160194
FUJ00160194
Page 4 Comments (Continued)
PS29+
There are no SLAs associated with general incidents raised via the Post Master /
Helpdesk support route.
I think RR is confusing the two incident streams.
Parker, Steve, 17/10/2018 03:23 PM
PS30 I can only do this for the incident management system used by SSC (Peak).
Information from the HSD systems (where the majority of hardware issues were
closed) is not available to me.
Parker, Steve, 17/10/2018 03:56 PM
54, 57
55, 56
26.
58, 59
60
61, 62
2%.
27.4
63 I
27.3
27.4
28.
29.
29.1
29.2
30.
31.
FUJ00160194
FUJ00160194
configuration information and Post Master transactions. The latter where then replicated to
central servers over communication links. ¢.e-[please-explain-whatthis-means]). This
means that such access was required in order for Fujitsu to support users.
The example given by Mr Roll ("when a binary bit would "flip", thus a "1" became a "0™) relates
to a configuration itemflag which can become locked in the wrong binary setting (1, 0). One
example of which would be a stock unit lock which, in the wrong state, would -preventing
updates to stock units within a branch. Correcting tFhis does nott involve accessing or editing
transaction. data any way or ree flat pases. The tool used to correct this issue is I
hi
ided-to the Cl
3
1
i La gS=
Where Mr Roll refers to re-creating the database I understand him to be referring to the process
that Fujitsu would follow i data became corrupted [how often would this happen?]. As
explained by Mr Godseth in paragraph 35 of his statement, in Legacy Horizon:-
all counter data was held in a bespoke message store’ and the data was replicated within each
branch to aill counter positions and from each branch to the data centres where it was held in the
correspondence server message stores;
any data inserted into the message store at the data centre (for example reference data or
authorisations for banking transactions) would be replicated back to the branch counters; and
selected data was then extracted from the correspondence servers to update Post Office's back
end systems.
If one of the sets of data became corrupted [how would Fu know it had-been corrupted 9] on
a counter SSC would delete the entire set of data on that counter and replace it with a copy of
the data from one of the other sources that had not been corrupted. While this process involves
deleting and replacing a set of data, no new data is produced; all that happens is that the correct
data is used to replace the data that has become corrupted. [It would have been necessary for
SSC to inform a branch before carrying out this task.] la
jithe branch tecitoise Horan whet hiswas happening
Mr Roll also claims that:-
"some errors were corrected remotely without the sub-postmaster being aware" (paragraph 16);
and
there were some errors where it was necessary to "download and correct the data and prepare it
for uploading back on to the post office computer, then call the postmaster to inform him that
there was problem and that we needed two or three minutes to correct it" (paragraph 17).
It is not clear what errors Mr Roll is referring to or how he says they were corrected. As
explained by Mr Godseth in paragraph 36 of his statement, users with sufficient access
permissions could inject additional messages (i.e. data) at the correspondence server and the
fact that such data had been injected in this way d be clearly identifiable. [Nete—GJ-now-
these-things- i i ing-the-b hl]
It may be that Mr Roll is referring to issues relating to the end of day concent i in Legacy Horizon.
Essentially there was a cut-off point for transactions every day [whattime® Pand each counter
hi write an end of day message to the branch's master counter to enable the master counter
to harvest messages (including details of transactions) to Post Office's back end systems.
Occasionally a counter in a branch would fail to write an end of day message and there was a
process for correcting it. The issue would be reported to SSC by way of a Peak (either as a
result of a call to HSD or sometimes FJ could spot issues via system events). In lay terms, SSC
’ A message means data and transaction data is a subset of the data in the message store.
‘AC_152319334_1 5
FUJ00160194
FUJ00160194
Page 5 Comments
PS31 Suggest this is removed since the document pertains to HNG-X. While it has the same
effect on HNG-X systems it was not the tooling used on the Horizon system Richard
was working on at the time.
Parker, Steve, 17/10/2018 01:21 PM
GJ32 That sounds like an HNG-X doc so probably not the correct one.
Gareth Jenkins, 15/10/2018 04:44 PM
GJ33 — Godeseth
Gareth Jenkins, 15/10/2018 04:45 PM
32.
32.1
32.2
33.
FUJ00160194
FUJ00160194
would force the counter to generate a report based on the data already in the counter; this would
not alter the transaction data. A message injected in this way would go into the audit trail.
[In summary:-
Fujitsu could not change transaction data; and
iections were clearly identifiable] {Why would-
Fujitsu could inject transaction data and suc!
I do not understand what Mr Rol ans when he says that SSC had the ability to "transfer
money remotely" (paragraph 18). Nor do I understand how a third party could have accessed the
system and I note that Mr Roll has not attempted to explain this (paragraph 18). It was not (and
is not) possible for Fujitsu to do anything with money in a branch. [As noted above, the only
thing they Fujitsu could do in theory was inject transaction data and it would only do so [insert
explanation]. [Could FJ in theory manipulate a branch’s transaction data in a way which
was detrimental to a particular SPMR and undetectable is simply wrong.]
‘AC_152319334_1 6
FUJ00160194
FUJ00160194
Page 6 Comments
GJ34 Events picked up by SMC and usually a failed counter that would not restart (hence a
call to HSD from the SPMR)
Gareth Jenkins, 15/10/2018 04:46 PM
GJ35 Yes it would. However it is likely that any attempt to use that counter would fail.
Gareth Jenkins, 15/10/2018 04:47 PM
GJ36 It was always possible. I had originally though that this was not routinely done, but
John pointed out last week at least one example of when it needs to be done at a
counter. NB that example is NOT transactional data.
We are now in the area of “normal practice” v “malicious coding”, which Torstein
excludes as “with malicious coding anything can be done”.
However I’m concerned that RR is implying that some people in SSC were being
malicious and I don’t know how we defend against that.
Gareth Jenkins, 15/10/2018 04:48 PM
PS37 _ Processes in place required that such transactions can be identified, usually a unique
node number (that could not come from a normal counter) or a unique user name.
Process again dictates that the branch is informed.
Transactions would be visible in Post Master reporting and audit trail.
Don’t know how to defend against the suggestion that a person with high levels of
access could act maliciously. It is true of any computer system that you have to trust
your “super users” and that the peer group would detect that “something wasn’t right”
Parker, Steve, 17/10/2018 03:40 PM
GJ38 There is no need to inform the branch and they might be unaware of it.
Gareth Jenkins, 15/10/2018 04:51 PM
GJ39 7pm
Gareth Jenkins, 15/10/2018 04:52 PM
GJ40 Add: to write a Branch EOD message, which would then trigger the data Centre to
Gareth Jenkins, 15/10/2018 04:52 PM
GJ41 Yes if done in process, but not necessarily if done maliciously
Gareth Jenkins, 15/10/2018 04:54 PM
GJ42 Main reason is for transactions stranded on a “dead” counter. There may have been
some cases where transactions were injected to correct a bug that had been identified.
Not sure if that was the case or not.
Gareth Jenkins, 15/10/2018 04:54 PM
FUJ00160194
FUJ00160194
Page 6 Comments (Continued)
SH43 Need a more robust rejection here. The position, as I understand it, is that FJ could
not do anything with money in a branch i.e. could not in any way transfer it into or out
of a branch and this needs to be explained. The only thing they could do in theory was
inject transaction data (not amend existing transaction data), that there was no point in
doing so (i.e. it was something they would only very rarely want or need to do) and
that it was anyway a pointless exercise since it would immediately be picked up by
Horizon’s checks. The key point, which I think does not yet come across in this draft,
is that the suggestion that FJ was able to manipulate a branch’s transaction data in a
way which was detrimental to a particular SPMR and undetectable is simply wrong.
Simon Henderson, 15/10/2018 10:44 AM
Track Changes
4
© MN DH RW ND
© © © © © WN NN NN NHNNN HN BS Bese aan a a a
A BON 566 B® NOAA KON BGO BANDA R DH FO
Change
Change
Insert
Insert
Insert
Insert
Insert
Insert
Change
Insert
Insert
Change
Change
Insert
Change
Insert
Change
Insert
Insert
Insert
Insert
Insert
Insert
Delete
Change
Change
Insert
Insert
Change
Change
Change
Insert
Change
Change
Change
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
17/10/2018 07:54 AM
17/10/2018 07:54 AM
17/10/2018 02:06 PM
17/10/2018 07:44 AM
16/10/2018 03:25 PM
16/10/2018 03:26 PM
16/10/2018 03:26 PM
16/10/2018 03:27 PM
17/10/2018 08:00 AM
16/10/2018 03:27 PM
16/10/2018 03:27 PM
17/10/2018 09:46 AM
17/10/2018 09:52 AM
17/10/2018 09:52 AM
17/10/2018 09:46 AM
16/10/2018 03:30 PM
17/10/2018 09:43 AM
17/10/2018 09:02 AM
17/10/2018 09:11 AM
17/10/2018 09:14 AM
17/10/2018 09:11 AM
17/10/2018 07:52 AM
16/10/2018 04:30 PM
16/10/2018 04:24 PM
16/10/2018 04:24 PM
16/10/2018 04:26 PM
17/10/2018 10:03 AM
17/10/2018 01:37 PM
17/10/2018 10:39 AM
17/10/2018 10:39 AM
17/10/2018 10:40 AM
17/10/2018 02:28 PM
17/10/2018 02:28 PM
17/10/2018 12:13 PM
17/10/2018 12:07 PM
FUJ00160194
FUJ00160194
Track Changes (Continued)
36
37
38
39
40
“1
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
Insert
Change
Insert
Delete
Change
Insert
Insert
Insert
Insert
Delete
Change
Insert
Change
Delete
Insert
Insert
Change
Delete
Insert
Delete
Delete
Insert
Change
Change
Delete
Change
Change
Change
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Parker, Steve,
Simon Henderson, 15/10/2018 10:22 AM
17/10/2018 12:07 PM
17/10/2018 12:07 PM
17/10/2018 12:09 PM
17/10/2018 12:14 PM
17/10/2018 12:13 PM
17/10/2018 12:15 PM
17/10/2018 12:16 PM
17/10/2018 12:23 PM
17/10/2018 12:25 PM
17/10/2018 12:26 PM
17/10/2018 12:26 PM
17/10/2018 12:26 PM
17/10/2018 12:26 PM
17/10/2018 03:01 PM
17/10/2018 01:11 PM
17/10/2018 01:12 PM
17/10/2018 01:12 PM
17/10/2018 03:36 PM
17/10/2018 01:15 PM
17/10/2018 01:15 PM
17/10/2018 01:15 PM
17/10/2018 01:15 PM
17/10/2018 01:19 PM
17/10/2018 01:20 PM
17/10/2018 01:20 PM
17/10/2018 01:21 PM
17/10/2018 01:21 PM
FUJ00160194
FUJ00160194