Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
IN THE HIGH COURT OF JUSTICE
QUEEN'S BENCH DIVISION
ROYAL COURTS OF JUSTICE
BETWEEN:
ALAN BATES & OTHERS
Claimant
AND
POST OFFICE LIMITED
Defendant
SECOND WITNESS STATEMENT OF STEPHEN PAUL
PARKER
I, STEPHEN PAUL PARKER of Lovelace Road, Bracknell, Berkshire RG12 8SN WILL
SAY as follows:
This is my second witness statement in relation to these proceedings. The facts set
out in this statement are within my own knowledge, or if they are outside my
knowledge, I have explained the source of my information or belief.
RICHARD ROLL'S SECOND STATEMENT
2.
I have previously commented on the first witness statement of Richard Roll dated
11 July 2016. 4 i bor-of respects that stat t 1
In his second statement dated 16 January 2019 (Roll 2), Mr Roll has clarified some
points and made some new points. I have been asked to comment on these points
and I do so below. Unless indicated otherwise, in this statement I describe the
position as it was when Mr Roll was employed by F ujitsu and references to
Horizonparagraph numbers are references to paragraphs in Roll 2.
Hardware failures
Mr Roll suggests in paragraph 5 that he encountered a hardware failure on average
at least once a month. That seems plausible to me, although it is not clear how Mr
Roll defines a ‘hardware failure’. To put it into context, there were around 28,000
counters in operation at any one time while Mr Roll was employed by Fujitsu and it
is inevitable that hardware failures would occur.
AC_153972771_4 1
FUJ00161730
FUJ00161730
5.1
5.2
Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
However, Mr Roll'’s statement that hardware failures “could and did affect branch
accounts" gives a misleading impression. It would be more accurate to say that
while a hardware issue could very occasionally prevernt-a—branch's—abilityto
carry_out-certain_transactionsdo so, the vast majority of hardware issues were
not capable of having any impact on a branch's accounts in terms of
ereatingleading to a financial discrepancy.
At paragraph 6 Mr Roll states that the 'most extreme case that he can recall was a
complete failure of a counter to communicate with the server...".. These are the
stuck transactions that I referred to at paragraph 43 of my first witness statement
(they were also known as ‘marooned transactions'). These stuck transactions
could only result in a discrepancy in a branch's accounts in very limited
circumstances:-
imln the event of a hardware issue preventing transactions conducted on one
counter from being replicated to the other counters in a branch, when a branch
reported the issue, Fujitsu engineering service would go to the site to attempt to
resolve it. As part of this engineering visit, actions would be taken to ensure that
transactions were replicated correctly. I am aware of a facility used by engineers in
these cases known as the “recovery laptop” but cannot describe the process-and.
itislt was only in the very rare circumstances where: (1) Fujitsu could not locate or
replay a replicated copy of the transactions ; and (2) the branch was unable to
advise which transactions had been carried out on the counter after it stopped
communicating-withthe-server that there might be a discrepancy in the branch's
accounts as a consequence of the issue. In these cases Fujitsu would notify the
Subpostmaster and Post Office and provide any supporting information that Fujitsu
was able to gather; Bs
evident from transfers by SSC to MSU to raise BIMS.
At paragraph 7 Mr Roll suggests that there were "PIN pad problems which caused
issues in branches and problems with other peripheral devices such as keyboards
which only occurred intermittently". I note that he does not explain if or how in his
view such issues might causehave led to discrepancies in a branch's accounts
(indeed he says that he cannot recall the specific detail of the issues). I am not
aware of circumstances in which PIN—pad. keyboard. issuesled—t
di: Pp ies-i: branch‘ tsthey would have done so. I suppose it is
theoretically possible that there could be a problem where a Subpostmaster
pressed one key and another number appeared on the screen, but that would be
obvious to the Subpostmaster when looking at the screen. In relation to keyboards,
AC_153972771_4 2
FUJ00161730
FUJ00161730
7A
7.2
7.3
74
Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
it may also be worth mentioning that if the physical keyboard did not work, there
was an onscreen keyboard available.
At paragraph 8 Mr Roll describes "one particular case where branch data was not
being replicated from a mobile post office correctly and it appeared that the
subpostmistress was turning off the power mid transaction. He goes on to say that
"[I] discovered that the button which should have put the laptop into standby mode
was actually switching off the power, resulting in the disk crashing. I disassembled
the laptops to confirm this". At my request, my colleague John Simpkins, Senior
Consultant, carried out a search of the incident management system and found two
incidents (Peaks PC0100174 {POL-0271797} and PC0100899 {POL-0272727})
that appear to relate to the work Mr Roll is describing. My colleague undertook a
keyword search for incidents containing the words "laptop" and/or "luggable" and/or
“outreach”, all of which are likely to cover the events described by Mr Roll in
paragraph 8 of his statement and finallyfoundthen added the incidents
usingword "switch" to locate these Peaks. Whilst I have no personal recollection
of this matter, based on Mr Roll's narratives on the Peaks it appears that:
a hardware fault was identified from equipment on "ONE" (Mr Roll’s capitalised
emphasis from his narrative_in the Peak) internal test rig {(POL-0271797}. I
assume from the context that this equates to one hardware item, although+
suppose it could conceivably relate to one test rig which comprises a number of
counters;
when a hardware unit was retrieved fromthe site reporting the issue, Mr Roll found
the unit to be "working correctly, no further action required" {POL-0272727},
there is nothing in Mr Roll’s incident narratives which record any discussion with Mr
Peach (Mr Roll's Manager at the time and whom I worked with for 17 years_before
he retired in 2010), its outcome or the provenance of any information Mr Roll may
have had relating to a faulty batch of hardware, although I note that no such
information is referred to in either Peak;
if Fujitsu was aware of a batch of faulty laptops as Mr Roll suggests it should and
I believe thatit-would have been investigated and the faulty batchweuld-have
been recalled. It was not in Fujitsu’s interests to have faulty equipment in
circulation. I would also have expected to have seen an update of the incident
describing any conversation Mr Roll had with engineering but no such update is
present. Further, I do not believe thatMr Peach would have kept an issue such as
this quiet as Mr Roll seems to be suggesting; and
AC_153972771_4 3
FUJ00161730
FUJ00161730
75
Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
again, I note that, Mr Roll does not explain whether or how such an issue could
have led to a discrepancy in a branch's accounts and I am not aware of any
circumstances in which that would happen. For completeness, I also note that
laptops were only used in mobile branches (also known as outreach branches) and
any potential impact would be limited to those branches. Although I don't have
exact figures, I understand from my colleague Matthew Lenton that mobile
counters represented around 1% of the total number of counters in use in the Post
Office network in 2006 (data is not available for the period that Mr Roll was
employed by Fujitsu).
Transactional Integrity
10.
At paragraph 9 Mr Roll alleges that "[Djata corruption and glitches sometimes
meant that transactions were not zero sum". He recalls "[...] on more than one
occasion where subpostmasters had problems with a deficit showing in their
accounts, and then as a result of working through a process to try and resolve it, the
deficit doubled". Given the lack of detail I cannot be definite, but after-consulting
my colleague Gareth Jenkins (Retired Horizon Architect} understand that Mr
Roll may be referring to KEL PSteed2847N {POL-0033658}, which relates to a
situation where a user attempted to reverse a Rem In of cash to an incorrect stock
unit and, because of a software error, the value of the Rem In was doubled instead.
This KEL is referred to in-beth my first witness statement-and-boththe-expert's.
If that is what Mr Roll is referring to, this KEL does not have anything to do with a
transaction not being a zero sum. It was first raised on 28 April 2003 and it was
agreed that any affected Subpostmaster would be contacted to say that the
problem was due to a software error and that they should ask NBSC for balancing
procedures {POL-0033658}. The NBSC was also told that the officebranch would
need an error notice for twice the amount of the rem-in,—SolutionRem In. The
issue was diagnosed on 28 April 2003 and solution FSTK_2_0_WP16353 was
created and sent out as a new software release _on 7'"-of May 2003 so that the
problem did not recur {POL-0262279}.
I am not aware of any circurstancescase in which baskets were not zero sum
(i.e. any circurastancescase in which a non-zero-sum basket was accepted into
Horizon), although given the lack of detail in Mr Roll’s statement on this point it is
difficult for me to state definitively that such an issue never arose. I would expect
these—circumstancesany such issue to result in a receipts and payments
mismatch which would be: (1) picked up by Fujitsu's reconciliation reporting or
AC_153972771_4 4
FUJ00161730
FUJ00161730
Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
event monitoring: (at HNG-X) erand; (2) visible to the branch when they balanced
at the end of the trading period. Either of these would result in investigation and
resolution by the SSC team.
11. In paragraph 10 Mr Roll is describing an issue caused by reference data (which
defines the path to be taken from the payment of a bill to the third party actually
receiving money) being incorrect. I cannot recall any instances of incorrect
reference data misdirecting payments while Mr Roll was employed by Fujitsu, but
reference data errors do happen and I recall an incident in 2010 involving the
Highland AuthorityCouncil. These are invariably human errors, in that mistakes
can be made by individuals when setting up reference data but only then-ifitwas.
entymissed_but- only then if it was-alsethese also have to be missed during
validation and verification before release.
12. When incorrect reference data is used, payment goescould go to the wrong Post
Office client and the customer's bill is not settled, but there iswould be no impact
on thea branch's accounts. If a customer came back to the branch and pointed out
that they had paid a bill that a utility provider, for example, was chasing them for,
then I would expect the Subpostmaster to escalate this via the Helpdesk / Post
Office, rather than processing the payment again without taking any money from
the customer. This sort of issue would be picked up quickly. I-the-Highland
Authority-i forred-to-ab. FWBD-t is hath: dh.
ws} ppened}- Peak
issue was reported at 08:21:53 on 1 February 2012 and by around 11:00am a
reference data download had been expedited to fix this issue.
13. At paragraph 11 Mr Roll alleges that there were problems which sometimes arose
after Subpostmasters used the recovery process. He states that "[TJhis might
suggest that there was a problem with the recovery process itself, or at least that it
was not as straightforward as it should have been". He does not articulate any
specific issues, which makes it difficult to comment.
At the time Mr Roll was employed by Fujitsu there were two transaction recovery
FE
processes:-13.1- AP recovery; and13.2— Bbanking recovery. 44-1 do not have
personal experience of these processes, but am aware that they are set out in the
branch documentation that Post Office issues to Subpostmasters.The_and their
design-of Horizon -in-this-regard is covered in APS Counter and Banking counter
Id_exj me_non-R&P ifi inter_eventi indi roblems. For
example, _in_PC0123699 [insert POL number] where a critical event “/fJailed to
AC_153972771_1 5
FUJ00161730
FUJ00161730
B
Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
design documentation {POL-0107388} and {POL-0061134}. 45.Byt heir nature
a, recovery processes requires. a user to complete a number of steps and where
several steps are required mistakes can be made. For that reason, recovery
processes are designed to be as simple as possible-and-._I note that Mr Roll has
not explained how he believes the recovery processes described above could have
been made more "straightforward", which again makes it difficult to comment.
46—Mr Roll states that "Fujitsu's stance was generally that if there was a problem
with transactions following a recovery process and if SSC could not identify the
cause, then the problem must have been caused by the Subpostmaster not
following the recovery process properly". I agree that if Fujitsu was unable to
identify the cause of a discrepancy that was said to relate to a recovery issue,
having investigated the matter, the likely conclusion would be that the discrepancy
(if there was one resulting fromfollowing the recovery process) was probably the
result of human error. The key point here is that the SSC would thoroughly review
all of the available evidence, and I am confident that if there had been a software
issue in relation to the recovery process, the SSC would have identified it or in the
very unlikely case that we could not determine root cause, would have at least
documented its symptoms. Having conducted a careful investigation which did not
reveal anys oftware issues, human error would be byf ar the most likely
explanation.
Transaction Corrections (TCs) and Patterns of Software Errors
16.
f
fe
47-Mr Roll states at paragraph 12 that he cannot recall Fujitsu carrying out any
analysis of TCs to try and identify if there had been an underlying software error.
TCs were not introduced until 2006, some two years after Mr Roll had left Fujitsu.
During the period that Mr Roll was employed by Fujitsu, Post Office sent Error
Notices to branches. Fujitsu would not have analysed Error Notices. They were
not within its remit, being dealt with by Post Office on the basis of its own back office
processes.
48-1 agree with Mr Roll's statement at paragraph 13 that "Ajithough it is correct
that high frequency problems were found during testing, it was impossible to test for
every permutation of data, and testing did not result in the identification of all
errors". The same could be said of every computer system in the world.
49.-At paragraph 14 Mr Roll disagrees with a statement made by Dr Worden that
“all software errors would have been picked up by processes which were in place,
or that the likelihood of software errors staying disguised as human errors was very
small". Mr Roll does this on the basis that "subpostmasters would have been held
responsible for problems which had not at any time been identified as software
AC_153972771_4 6
FUJ00161730
FUJ00161730
ie
B
R
Is
Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
errors, either because they could not identify the problem and did not pursue these
with Post Office or Fujitsu, or because when they were raised we (Fujitsu) were
ultimately unable to identify the problem at the time."
20.Fujitsu has mechanisms in place for detecting potential issues. In paragraph
26.1.1(b) of my first statement I briefly explained that the System Management
Centre monitors system events and I briefly described the work of the
Communications Management team in paragraph 26.1.2. Each of these teams
would generate support actions based on system generated event information. It is
also the case that the sheer number of Subpostmasters using the service and
reporting issues via the Help desks make it very unlikely that there is any significant
number of hidden errors. These mechanisms are so effective at identifying when
bugs are a cause of problems and it would be very rare for a bug to not be detected.
24.-Once an issue has been raised, Fujitsu is experienced in providing support and
will go to great lengths to investigate the root cause-of an-issue. In paragraph 61 of
my first statement I explained.at-paragraphs-64—64.46 that Fujitsu use a custom
solution, developed and administered by the SSC, which allows us to record
support knowledge into a Known Error Log (KEL). KELs record support knowledge
which is intended to assist staff in the support and understanding of the Horizon
system.
22.Mr Roll's statement that "subpostmasters would have been held responsible for
problems which had not at any time been identified as software errors... because
when they were raised we (Fujitsu) were ultimately unable to identify the problem at
the time" assumes that if Fujitsu was not able to get to the root cause of an issue, it
must have been a software error rather than a human error. But as I explain in
paragraph 15 above, if Fujitsu was unable to identify any software issues after
carrying out a careful investigation, human error would be by far the most likely
explanation.
23.On the odd occasion Fujitsu may identify that there is a software issue but we
may not get to the root cause of an issue-—This_and take a decision not to take
matters further. Such a decision would generally be where an issue is
determined to be low priority and low impact. Such-a-decision It would be made by
the development / architectural group in conjunction with POL, not by the SSC. If
the issue was causing a financial impact in a branch's accounts, it would be treated
as high priority and high impact as I explained in paragraph 62.8 of my first witness
statement. In such cases, the Fujitsu Support and Development organisation would
keep going until it identified the cause of the software issue. This might even
include generating bespoke code in the application to generate additional
diagnostics (Mr Roll would not have carried out such work). Even a problem
AC_153972771_4 7
FUJ00161730
FUJ00161730
B
Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
exhibiting minimal financial loss (in terms of value) would be treated as essential to
fix for the financial integrity of the system.
24 think that Mr Roll may be trying to suggest that Fujitsu were quite happy to
assume that issues were the responsibility of Subpostmasters. That is not the
case. We investigated matters thoroughly and if we identified an error in Horizon,
we dealt with it appropriately. Our investigative and analytical procedures have
always been thorough in my view and while I obviously cannot say that in each and
every case our diagnosis was correct, I am confident that that was the case in the
overwhelming majority of cases.
Testing of software and development fixes
25.
25.-At paragraph 15 Mr Roll alleges that during his time at Fujitsu there were
“budget pressures and redundancies which impacted system development and
testing" and which "negatively affected the test regime". \t is true that Post Office
would want to resolve issues quickly, in particular those which were causing major
issues-quickly, and it is also true that, like any other business, Fujitsu operated
within a budget. However, points such as this did not affect the quality of
development or testing that was done. Fujitsu would not knowingly release
something that did not or might not work and there were often times when releases
were delayed to give Fujitsu more time to carry out testing. I would also mention
that Mr Roll would not have had any first hand visibility of budgets in his role.
26-At paragraph 16 Mr Roll alleges that the SSC team and Fujitsu were generally
under pressure "due to an awareness of the financial penalties imposed by Service
Level Agreements between Post Office and Fujitsu" __At paragraph 43 of my first
witness statement I explained that the possibility of financial penalties or Service
Level Agreement breach was never a factor which affected the diligence with which
SSC would investigate an issue. By way of further explanation:
Schedule 15 to the “Service Level Targets for Horizon Services”
{POL-0084662}, which i WBDto insert
@SSerPHSA) contains the agreed service levels and remedies in force as part of
the "varied and restated" Codified Agreement between Fujitsu and Post Office
dated 3
AB i tate The Service Level Agreements
were concerned with the overall flow of data through the estate and the need to
ensure requisitethat transaction data byreached its destination within certain
time limits.
27,Whilst-th fi ial Ities for-late-ti tion-dat: for-dat:
that-did-not-h: Hof the required fields populated when it tto-Post
AC_153972771_4 8
FUJ00161730
FUJ00161730
25.4
Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
Office, thereThere were no_specific financial penalties relating to the SSC
processing of incidents. {POL-0406084}, whichis theThe Service Description for
Third Line Software Support Service (-explained-at paragraph26.3-of my first
“There are no specific service targets linked directly with this service_{i.e. the
SSC]. However, attainment of all data delivery Service Level Targets, as detailed in
Annex 2 of Schedule 15, wasis directly related to the successful provision of this
service.The SSC-did-h. perationaltargets-to-t dent d-based.
* fi ; lod if
ea
28.Penalties on delivering transactions were assessed on a per transaction basis
Therefore, if there- werefor example a large number of transactions_did not reach
their destinations on tim I suppose that penalties could in theory add up to the
type of figure Mr Roll refers to in paragraph 16. However, any penalties would not
have changed the SSC's attitude as to the level of diligence carried out. I agree that
such penalties were sometimes talked about in the support community but as far as
I am aware Fujitsu was never charged any large penalty. In my opinion that is
because Fujitsu did a good job and not because they cut corners to avoidthem, as
Mr Roll seems to be suggesting. I would say that it is the nature of the support
environment that you only ever see the transaction that goes wrong andare not
conscious of the millions of transactions that worked faultlessly. This can skew
one’s perception of the system as a whole.
The SSC had* operational targets to turn incidents around based on an order of
priority", As explained in paragraph 22 above, if an issue was causing a
financial impact ina branch's accounts, it would be treated as high priority
and high impact_by SSC. However", any increase in priority would not
*adversely “impact the diligence with which work was done. *
Identifying Unexpected Events
26.
29.1 agree with Mr Roll when he says that "Horizon's ability to identify unexpected
events depended on how it was designed and programmea" at paragraph 19. It is
correct that if the SSC found something that should have been picked up by the
system they would notify developers so they could fix the softwareor ensure that a
warning was generated to cause support action to take place. Anything which had
the potential to affect branch accounts would be considered to be high impact and
was raised with the development group for root cause fix.
AC_153972771_1 9
FUJ00161730
FUJ00161730
Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
Transaction Injection in Old Horizon
28.
EE
30.In paragraph 20 of Roll 2, Mr Roll describes a process by which transactions
could be inserted via individual branch counters by using the correspondence
server to piggy back through the gateway. He has not previously made this point
clear. Now that he has, following a discussion with {fA
{SBHIS}colleaques who performed such actions I can confirm that this was
possible. I did not mention it in my first witness statement because, when faced with
a less clear account in Mr Roll's first statement, my recollection was that if it was
necessary for the SSC to inject a transaction data into a branch's accounts, it would
have been injected into the correspondence server and_{injecting via the server
was the default option which was followed in the vast majority of cases).
34.-PC0175821 {POL-0345994} is an example of data being injected into the
counter. I was not involved in this incident, but having reviewed the Peak I can see
that z=:
this incident concerned five corrupted bureau transactions on the counter.—z
Post Office contacted the manager and they did another balance with the correct
declarations. This resulted in a net gain of £40.85.—10,85;
Post Office agreed to the SSC taking corrective measures by inserting messages
which caused an equal but opposite effect and this resolved the issue-Details:
28.5 __details on the email conversations with POL (including their authorisation) are
B
attached to the Peak along with confirmation that the Branch Manager was
contacted.
32-At my request, my colleague John Simpkins (Senior Consultant), carried out a
search of the incident management system for incidents which required injecting
data into the counter. From the results I can determine thal tRiswas-only-done-is
AC_153972771_4 10
FUJ00161730
FUJ00161730
Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
29.3 correcting configuration data after a PinPad change:
29.4 __removing redundant configuration items:
29.5 a ing fi a
29.6 oe inf .
30.
In total, there were 14 such incidents. Of those, only [insert number] involved
E
8
transaction would appear on the transaction logs available on Horizon as if it had
been carried out by the user that was logged into the counter at the tine (if nobody
was logged on, the User ID would be missing). WhenHowever, when injecting
such a transaction, the SSC user whould ensure that it was clearly identified in the
audit trail as having been inserted by SSC. Examples of such identification I am
aware of are the use of a SSC user as the ClerkIDClerk ID and / or details of the
incident number as an additional property.
33-At paragraphs 21 and 22 Mr Roll states that both himaselfhe and the "SSC team
generally had the ability to inject data" and that "there was no limit on the type of
transaction that we could insert". At paragraph 20.2 of my first statement I said that
“some" members of the team could do this, but this was badly stated. Everyone in
the SSC team had the ability to inject data. My intention was to express the fact that
only limited numbers of SSC technicians ever needed to constructinject financial
data.
34.-There were (and are) strict procedural controls in place relating to injecting
transaction data into branch accounts.The-Access-Control Policy can-be-found
at-Exhibit SP2-pages-x-to-x {WBD-note—this-h: t-been-disclosed—to-b
di}. Thi 1 6. J. -ds-of the-actions to-be-tak:
poley-req
syst tonded-within the Post Offi tthat OCPs and OCR.
were and/are_very_rare.*The SSC_was_{and_is}_hugely_reluctant_to_change.
fi I dat that their job-and they thi f
hich th:
AC_153972771_4 11
FUJ00161730
FUJ00161730
Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
followed in practice. The Access Control Policy can be found at Exhibit SP2
D J ection 4.5. ate
has been corrupted by faulty code.) Correction of data must be subject to
33,___Section 4.5.5.4 goes on to state that:
is
35.
. .
identifying _what has been changed (before _and_after_values) and_the
*The SSC was (and is) hugely reluctant to change financial data as that was not
their job and they recognised the seriousness of doing so.
With reference to Dr. Worden's statement that "as for transferring money, Horizon
includes no functionality that allows payments to be made to external parties or
account", at paragraphs 20.1, 20.3, 21 and 58.4 of my first statement I said that
money could not be transferred, by which I mean that it could not be transferred into
a third party's bank account. Following-a-discussion—with_Gareth Jenkins
discussed it with my colleagues and we have now theorised that someone could
have carried out a Post Office transaction, such as a GIRO transfer or a utility bill
payment. A GIRO transaction would have been detected as part of Post Office's
reconciliation processes because there would be no accompanying paper
document. There is no accompanying paper document for a utility bill payment, so
in theory such a transaction would not be detected through reconciliation. I am not
aware of any such activity ever taking place and _if it had occurred it would have
resulted in instant dismissal.
Rebuilding branch transaction data
36.
At paragraph 23 Mr Rolls describes the process of "rebuilding branch transaction
data". As part of this process he alleges that transaction data was "corrected" by
copying it to the SSC, altering it whilst on the SSC's computers and then
downloading it back to the branch and that there was a risk of data not being
accurately copied across or even deleted. He goes on to say that this was
sometimes done without a Subpostmaster's knowledge at paragraph 24.
AC_153972771_1 12
FUJ00161730
FUJ00161730
37.
37.1
37.2
38.
38.1
Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
In paragraphs 55.3 and 55.4 of my first statement I described what happens if one
of the sets of data on a branch counter became corrupted. I explained that:-
while this process involves deleting and replacing a set of data, no new data is
produced; all that happens is that the replicated data is used to replace the data
that has become corrupted from another counter in the branch; and
it would have been necessary for the SSC to inform a branch before carrying out
this task because it is likely that any attempt to use that counter would fail while the
process was being carried out.
‘nEor completeness, in the rare circumstances where it was necessary for Fujitsu
to rebuild transaction data_in Legacy Horizon, there were three possible scenarios
[which are set out in {POL-0107388}: the firstis.
when a counter fails;-th: ei ter-h: “bh death";
and-thereisfailed and there was a complete replication of that
counterscounter's transactions elsewhere, Fujitsu simply deleted the message
(transaction) store on the faulty counter and alowused the standard facilities of the
Riposte software to re-build the data from the replicated copy._In this scenario,
the branch would be unable to use the counter while this process was
carried out (it would be in “recovery mode”):
40,Wherew! no replicated copies of the transactions existed, Fujitsu would
physically retrieve the disk from the Counterfaulty counter. The disc tes
Fujitsushould hold all of the transactions that haved taken place—Fujitsu-can_on
he ii in office, the SSC would extract the transaction data and
put it into a replacednew replacement counter without amending theat data. The
SSC would need the Subpostmaster's memory card (AKA PMMC) to de-crypt the
data. This was a physical card (a Subpostmaster had two) and Fujitsu would have
to borrow one - this shows-thatso the Subpostmaster had-tewould know what
was going on._One of these cards has to be present in the interface slotin
error.44. happening. _If Fujitsu were to remevechange anything, it would be to.
remove the envelope around the transaction data. The envelope contains the
system admin data, i.e. the sequence number of the data andits ID. Fujitsu would
not change the tran: data itself and in removing the envelope data, they
would simply be allowing the system to automatically re-number the transactions
when they were re-inserted. Ultimately, when the counter was replaced at the
branch the Subpostmaster would be able to see what Fujitsu had done. I recognise
AC_153972771_4 13
FUJ00161730
FUJ00161730
Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
this is contrary to what I said at paragraph 55.5 of ny first witness statement. This
is because I was not entirely clea on the points being made by Mr Roll when I was
responding to his first statement.
42-In the rare cases where Fujitsu werewas not able to access a portion of the
transaction data from the disk then we would use-replicatedreplicate
transactions as far as they:we were able to and would notify Post Office and the
Subpostmaster of this and any information we had on the extent and potential
timing of any missing transactions.
Additional Clarifications
9.
43.-At paragraph 25 of his statement, Mr Roll states that "/...] whilst my workload
did involve some support to engineers opening and closing branches, I would
estimate that this made up only 30% of my work, and the majority of my workload
(estimate 70%) involved looking for faults on data stores, preparing reports for the
manager as a result of problems with Horizon experienced by the Estate, [..]." I do
not agree-withaccept the alleged percentage split of Mr Roll's workload_or his
explanation as to why that split was not reflected in Fujitsu’s records. At Mr
Roll's level, the vast majority of his work would be recorded as attributable to him.
As for his suggestion "a group of perhaps 4 or 5 SSC staff could end up working on
the same problem, but for recording purposes this would be assigned to one person
[...].", it is possible that workload could be re-assigned to another person in the
event of sickness, rare skills being required on more urgent work or a change of
skillset being needed as an incident progresses. Wherever possible we would
ensure that the same SSC person worked through an incident to resolution to
ensure continuity. The suggestion that 4 or 5 people would work on the same
problem is an extreme case.
STATEMENT OF TRUTH
I believe that the facts stated in this witness statement are true.
Signed:
Name:
Date:
AC_153972771_4 14
FUJ00161730
FUJ00161730
FUJ00161730
FUJ00161730
Claim No: HQ16X01238, HQ17X02637 & HQ17X04248
AC_153972771_4 15
Document comparison by Workshare 9 on 29 January 2019 11:58:07
Input:
[Document 1 ID
linterwovenSite://DMS.WBD-UK.COM/Active/153977420/1
[Description
#153977420v1<Active> - For comparison
[Document 2 ID
linterwovenSite://DMS.WBD-UK.COM/Active/153972771/1
[Description
#153972771v1<Active> - Second Witness Statement of
[Stephen Paul Parker 29 Jan 19
[Rendering set
BD - Basic - colour
Legend:
Insertion
Deletion.
owed fren”
Moved to *
Style change
Format change
Moved-dele
Inserted cell
Deleted cell
Moved cell
Split/Merged cell
Padding cell
Statistics:
Count
Insertions 167
Deletions 124
Moved from 4
Moved to 4
Style change 0
Format changed 0
[Total changes 299
FUJ00161730
FUJ00161730