ICL Pathway
Release 1C Change Request
Lost Transactions & Duplicate Payments
FUJ00078136
FUJ00078136
CS/CCN/xxxx
1.0
21 Jan 1998
Document Title:
Abstract:
Distribution:
Document Status:
Document Predecessor:
Author:
Approval Authority:
Signature/Date:
Release 1C Change Request - Lost Transactions & Duplicate
Payments
This document is submitted in support of CCNxxxx / CP1004 and
presents ICL Pathway’s proposal to modify the system processes
and counter procedures which, in their current state, have resulted
in many incidents of benefit encashment transactions being lost
and in some cases resulted in duplicate payments being made.
PDA:
Colin Oudot
Stewart Riley
Gareth Lewis
Tom Patterson
ICL Pathway :
Tony Oppenheim
Terry Austin
John Dicks
Mike Coombs
Martyn Bennett
Liam Foley
Stephen Muchow
Final
None
Stephen Muchow
Stephen Muchow
Customer Service Director
ICL Pathway
COMMERCIAL IN CONFIDENCE
Page I of 4
FUJ00078136
FUJ00078136
ICL Pathway Release 1C Change Request Ref: CS/CCN/xxxx
2 1.0
Lost Transactions & Duplicate Payments —_Date: 21 Jan 1998
1. Introduction
Since implementing Release 1C in November 1997, there have been 39 cases where a
benefit encashment transaction has been performed but no record of that transaction
was secured in the Horizon system. In 36 of these cases, the problem was identified
speedily enough to avoid the consequential potential problem of a duplicate payment. In
the remaining 3 cases duplicate payment was not avoided. The liability for the value of
the duplicate payments rests with ICL Pathway.
This document is submitted in support of CCNxxxx and presents the underlying root
cause and impact of the problem and several mitigating actions which have been
considered in the process of compiling ICL Pathway’s proposed solution, for which the
approval of the sponsors is sought.
2. I Root Cause and Impact of the Problem
Although this problem was predicted to be likely to occur before Release 1C was
authorised for implementation it was not anticipated that it would occur so frequently as
has been experienced.
The problem arises because the counter procedures for benefit encashment are not being
executed fully to completion by some counter staff. After the payment receipt has been
signed and checked, the counter clerk should pay the beneficiary and ‘commit’ (press
the finish button) the transaction whereupon it is securely written away to the system’s
message store. If the counter clerk fails to perform the ‘commit’, the transaction is not
written away and if subsequently the terminal times-out, the transaction is lost and the
payment is not marked as having been paid. When left in this state, the payment is
available on the system to be paid - again - a duplicate payment !
[DN: What happens if a transaction is not committed and the next action is to swipe
another card?]
The 39 incidents discovered to date have been associated with only 23 of the 205
offices in operation at Release 1C. [This could still relate to the number of cards in
circulation in the ‘new’ offices, therefore it could increase significantly]
Incidents per Post Office Number of Post Offices Total Incidents
0 182 0
i 16 16
2 3 6
3 2 6
3 1 5
6 1 6
TOTAL 182 + 23 =205 39
The total value of duplicate payments that were not avoided and for which ICL
Pathway owns liability is £86.20 whereas the total value of potential duplicate
COMMERCIAL IN CONFIDENCE
Page 2 of 4
FUJ00078136
FUJ00078136
ICL Pathway Release 1C Change Request Ref: CS/CCN/xxxx
Version: 1.0
Lost Transactions & Duplicate Payments —_Date: 21 Jan 1998
payments, i.e. those that were successfully avoided, is £1227.00. This represents only a
very small proportion of the number and value of benefit payments made correctly.
[Suggest deleting - it creates the wrong impression! ] It is of prime importance that
BES provides for the payment of the right benefit to the right customer - once. If
allowed to continue uncorrected, the credibility and acceptability of the solution would
be put at risk. A growing awareness, in certain quarters, of this potential weakness in
the system might be construed as an encouragement to attempt to obtain benefits
fraudulently, or worse.
3. Mitigation Actions
Several mitigating actions have been considered :
Option For Against
1 I Reinforce procedures: Tackles the problem Not clear how successful this
¢ visit offending offices I directly. may be over time
© issue general reminder.
[to all offices? ]
2 I Review training and the Needs to be fed into Will not help in Release 1C
implementation program planning for the next
(delay before practice) roll-out.
3 I Monitor enforced log-outs I Feasible and would Checks would be for all
and check with post enable checks against enforced log-outs, not just
offices the next day. retained receipts. where transactions are lost.
Recovery, if needed, is not
always possible next day and
gets the wrong date, time &
transaction id.
4 I Extend the enforced log- 74 minutes should cut Too long leads to exposure
out period: incidence significantly, I not only to duplicates (at
© now 15+ 14 minutes in particular where post I another outlet) but also in
e should be 15 +59=74 I offices shut for lunch. general security terms, e.g. in
© could increase further unattended post office at end
of day.
5 I Bleep and flash to attract Would attract attention I Flash may be ruled out on
attention shortly before an I if the post office is health and safety grounds
enforced log-out. attended. (e.g. epilepsy).
Would not work if post office
unattended or sub-postmaster
deaf, so only partial solution.
6 I Commit transactions on Most likely action to Very small risk of
the stack at enforced log- I capture data of true repudiation if transaction
out. encashments. Most would have been made void.
timely in terms of This is unlikely but need
system data reflecting process to minimise the
transaction time. potential impact.
COMMERCIAL IN CONFIDENCE
Page 3 of 4
FUJ00078136
FUJ00078136
ICL Pathway Release 1C Change Request Ref: CS/CCN/xxxx
Version: 1.0
Lost Transactions & Duplicate Payments —_Date: 21 Jan 1998
[Ifa telephone survey is being undertaken with all offices, is there an opportunity to re-
inforce the message?]
4. Recommendations
ICL Pathway recommends that all of the following options are implemented as part of
the overall attack on the problem:
¢ option 1 is already in train with POCL regional management
© option 2 will be fed into New Release 2 planning by Stephen Muchow
¢ option 4 with software fix to time-out period (74 minutes)
© option 6 with associated process and procedural initiatives to minimise any
adverse impact from potential repudiation
Option 6 will be supported further by the following Pathway initiatives :
e develop a daily MIS report to list encashments that were forcibly committed
e check any repudiations against the list, and pay by Cashcheque immediately if
matched and follow up with detailed investigation
e work with BA to develop enhancements to BA office procedures to recognise
the (very small) potential for repudiation actions and initiate the checks needed
e develop and agree the associated changes to Payment Card Help Line
procedures and Counters Operation Manual (minor change).
Since the vast majority of encashments performed are genuine and legitimate and only
an extremely small number of encashments are voided at the counter, the chances of a
void transaction being falsely committed are extremely small indeed.
[DN: Not sure this gains any brownie points - better suggest a plan for implementation]
It is believed that the probability of instances occurring where a transaction is forcibly
committed when it was intended by the counter clerk to be voided is so small that it will
be insignificant during the life of Release 1C. ICL Pathway will commit resources to
continue the analysis of this problem with the objective of improving our proposed
solution design for New Release 2.
COMMERCIAL IN CONFIDENCE
Page 4 of 4