ICL Pathway
BA
POCL
Reconciliation Process For ICL Pathway
Release 1c - PART 2 (Resolution)
FUJ00058360
FUJ00058360
Benefit Payment End to End Ref. CS/PRD/0003
Version: 2.0
Date 14/09/98
Document Title:
Document Type:
Abstract:
Status:
Authors:
Benefit Payment End to End Reconciliation Process For ICL
Pathway Release 1c - PART 2 (Resolution)
Process Definition - Jointly developed by ICL Pathway, BA and
POCL
Benefit Payment Reconciliation Processes for ICL Pathway
Release Ic are divided into seven parts. Part 1 deals with
reconciliation incident management. This part (Part 2) describes
reconciliation resolution processes. Part 3 focuses on liability
assignment. Part 4 defines the interactions with service and
problem management. Part 5 describes the interactions with fraud
management. Part 6 defines the ICL Pathway Reporting
Adjustment process, which forms part of the DSS/ICL Pathway
financial controls. Part 7 describes contingency arrangements for
reconciliation.
Continuous improvement will be applied to all seven parts during
the life of Release 1c to ensure that reconciliation continues to be
managed in the most effective manner.
Included within this document are process models for the
resolution of benefit under or overpayment and the resolution of
BPS transaction data exceptions in the return leg (BES to CPCS).
These models provide a common framework for the development
of local procedures.
Version 2.0 Baselined
Bob Davis - ICL Pathway Customer Service, Jenette Stark/Brian
Breheny - BA CAPS Business Modelling Team.
© 1998 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Page 1 of 95
ICL Pathway Benefit Payment End to End
BA Reconciliation Process For ICL Pathway
Release 1c - PART 2 (Resolution)
POCL
FUJ00058360
FUJ00058360
Ref: CS/PRD/0003
Version: 2.0
Date 14/09/98
0 Document control
0.1. Document history
light of experience.
Version I Date Reason
LA 30.10.97 I First draft.
1B 03.11.97 I Updated with urgent comments to establish a holding baseline.
1.C 07.11.97 I Updated to reflect: extra points for “Investigation”; the provisional
agreement not to include a process for recovery of any lost card-
impound transactions; and to note that all decisions have been made
on the basis of forecast volumes and may be urgently revised in the
1D 25.11.97 I Consolidation of comments received.
LE 06.04.98 I Draft issued for internal review.
LF 22.5.98 Draft issued for internal sign-off
1G 24.6.98 Draft re-issued for internal sign-off
1H 10.7.98 I Draft issued for external review
LI 04.8.98 I Draft issued for external sign off
2.0 02.09.98 I Draft to PET for sign-off
2.0 14.09.98 I BASELINED
0.2 Approval authorities
Vince Gaskell Executive Team
Name Position Signature Date
ICL Pathway Ltd. Director: ICL
Stephen Muchow Pathway Customer
Service
DSS CAPS Programme
POCL Business Integrity
Ruth Holleran Manager
COMMERCIAL IN CONFIDENCE
Page 2 of 95
ICL Pathway
POCL
Benefit Payment End to End
BA Reconciliation Process For ICL Pathway
Release 1c - PART 2 (Resolution)
FUJ00058360
FUJ00058360
Ref: CS/PRD/0003
Version: 2.0
Date 14/09/98
0.2a Authors
Name Position Signature Date
Jenette Stark BA CAPS
Brian Breheny BA CAPS
Bob Davis ICL Pathway Ltd
0.3. Associated documents
Reference Vers I Date Title
PDA/SUM/CP/001 I 2.1 I 31/01/98 I Service Code Of Practice For Help Desks (SCoP)
CS/PRD/0008 1.0 I 23/07/97 I ICL Pathway BA/POCL Payment Reconciliation
Reporting Process - Release Ic
CS/PRD/0009 1.0 I 23/07/97 I ICL Pathway Benefit Payments Service Exception
Resolution Process
CAPS/POM/BS/ CAPS Business Support Procedures
PRO/001.006
COLS/PR/0001.01 CAPS Operations and Live Support (COLS)
Procedures Manual
INV_1C.DOT 1.0 Investigation Procedures For Release 1c
CS/PRD/0002 2.0 I 27/04/98 I Benefit Payment End to End Reconciliation Process
For ICL Pathway Release Ic - Part I (Incident
Management)
Benefit Payment End to End Reconciliation Process
For ICL Pathway Release Ic - Part 3 (Liability) - Part
4 (Problem Management) - Part 5 (Fraud) - Part 6
(Reporting Adjustments) - Part 7 (Contingency)
CS/PRD/0034-41 TBA Benefit Payment End to End Reconciliation Process
For ICL Pathway Release 2
COMMERCIAL IN CONFIDENCE Page 3 of 95
ICL Pathway
BA
POCL
FUJ00058360
FUJ00058360
Benefit Payment End to End Ref. CS/PRD/0003
Reconciliation Process For ICL Pathway Version: 2.0
Release 1c - PART 2 (Resolution) Date 14/09/98
0.4 Abbreviations
A&L
ABED
AP
APS
ASG
BA
BAB
BAB(PA)
BES
BPS
BSU
CAP
CAPS
CBDB
CFM
CMS
COBAP
COLS
COM
CPCS
CR
cso
CSU
DEX
DN
DP
DPU
DQ
DSS
Alliance and Leicester (ICL Pathway)
Automated Benefit Encashment Database (POCL)
Authorised Payment (DSS/ES/SSA(NI))
Automated Payment Service (POCL)
Application Support Group (DSS/ES/SSA(ND)
Benefits Agency
Banking Accountancy Branch (DSS/ES/SSA(ND)
Banking Accountancy Branch (Programme Accounting)
(DSS/ES/SSA(NI))
Benefit Encashment Service (POCL)
Benefit Payment Service (POCL)
Business Support Unit (ICL Pathway)
Cash Account Period (POCL)
Customer Accounting and Payments Strategy
(DSS/ES/SSA(ND))
Counter Business Database (POCL)
ICL Computer Facility Management (ICL Pathway )
Card Management Service (ICL Pathway)
Corporate Banking and Methods of Payment Group
CAPS Operations and Live Support (DSS/ES/SSA(ND))
Counters Operations Manual (POCL)
Customer Payment Computer System (DSS/ES/SSA(ND))
Change Request (DSS/ES/SSA(NI))
Computer Support Officer (DSS/ES/SSA(NI))
Card Support Unit (DSS/ES/SSA(NI))V
Dialogue Expert (DSS/ES/SSA(NI))
Drafters Note
Due Payment (used to show data flows in diagrams)
Data Processing Unit (POCL)
Drafters Question
Department of Social Security
COMMERCIAL IN CONFIDENCE Page 4 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
DSS (CBC / DO) Department of Social Security(Child Benefit Centre / District Office)
DSS/ES/SSA(NI) Department of Social Security/Employment Services/Social Security
Agency (Northern Ireland)
E Encashment Transaction (used to show data flows in diagrams)
ED Expert Domain
EDIMS Expert Domain Incident Management System
EPOSS Electronic Point of Sale Service (POCL)
EVP Extended Verification Procedure
FAD Financial Accounts Division (POCL)
FBS Feeder Benefit System (DSS/ES/SSA(NI))
FSG Fraud and Security Group (DSS/ES/SSA(ND)
HSH Horizon System HelpDesk (ICL Pathway)
ICL Pathway ICL Pathway Limited
ID Identity
IOP Instrument Of Payment
IPMS Incident and Problem Management System (ITSA)
ISDN Integrated Services Digital Network (ICL Pathway)
ITSA Information Technology Services Agency
LAN Local Area Network (ICL Pathway)
MIS Management & Information Statistics
MOP Method Of Payment (DSS/ES/SSA(N}))
NINO National Insurance Number
NPO Nominated Post Office
PAB Personal Acting Body
PACS Programme Accounting Computer System(DSS/ES/SSA(NID))
PAS Payment Authorisation Service (ICL Pathway)
COMMERCIAL IN CONFIDENCE Page 5 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway Version: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
PCHL Payment Card Help Line (ICL Pathway)
PDCS Personal Details Computer System (DSS/ES/SSA(NI))
PinICL PinICL (an ICL Pathway incident management system)
PI Payment Instruction (DSS/ES/SSA(NI))
PID Personal Identification Device
PO Post Office
POCL Post Office Counters Limited
PPD Processes and Procedures Description (POCL/ICL Pathway)
PUN Pick Up Notice
QA Quality Assurance
RED Reconciliation Exception Database (ICL Pathway)
SADD Service Architecture Design Document
SCoP Service Code of Practice (DSS/ES/SSA(NI))
SHD Service Help Desk (DSS/ES/SSA(NI))
SMC. System Management Centre (ICL Pathway)
SoA Seal of Approval (DSS/ES/SSA(NI))
ssc System Support Centre (ICL Pathway)
TIP Transaction Information Processing (POCL)
TMS Transaction Management Service (POCL/ICL Pathway)
TP Transaction Processing (POCL)
vO Voluntary Offer (DSS/ES/SSA(ND)
WAN Wide Area Network (ICL Pathway)
COMMERCIAL IN CONFIDENCE Page 6 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref: CS/PRD/0003
BA Reconciliation Process For ICL Pathway sersion: 20 0/98
Release 1c - PART 2 (Resolution)
POCL
0.5 Glossary of Terms
The following glossary is generic, not Release specific. The contractual terms in italics are those
used in the Related Agreements (Schedule A01-Interpretations). Any comments on the wording
of the contractural terms (in ifalics) should be referred to the Joint Contracts Team based in
Terminal House, London.
Account
A record of a customer or other payees details held on a computer system.
Agency
In this context, it is used to describe the Benefits Agency, War Pensions Agency,
Employment Services, and the Social Security Agency (Northern Ireland).
Alternative Payee
A person entitled to collect certain benefits, allowances or pensions on behalf of a partner
as defined in Regulation 36 of the Social Security (Claims and Payments) Regulations
(1987). Guardians Allowance (not included in Regulation 36) also permits the alternative
payee facility.
Appointee
A person appointed by the Secretary of State in accordance with the
provisions of Regulation 33 of the Social Security (Claims and Payments)
Regulations.
Authorised Officer
A person who is authorised locally to contact the PCHL.
Authorised Person
A person authorised by the DSS, or the relevant Beneficiary or an Appointee, to collect
an Authorised Payment. An Authorised Person could be the Beneficiary or Appointee, or
any of Alternative Payee, Casual Agent, Permanent Agent, or Signing Agent.
Authorised Payment
A single amount of a particular benefit type authorised by the DSS as being due to a
specified Beneficiary on a specified date.
Authorised User
A person who has been granted access to certain restricted computer dialogues/functions.
Authority to Pay
The form a customer or PAB completes and signs to authorise an agent (standing or
casual) to collect Payment Card payments from the PO on their behalf.
COMMERCIAL IN CONFIDENCE Page 7 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
Automated Benefit Encashment Database
Post Office Counters Limited database which receives encashment records from ICL
Pathway, by Post Office, for benefit encashments made via the Benefit Payment System
in order to produce a weekly “supporting” document for reconciliation against each Post
Offices cash account. It also produces a daily “reconciliation” statement to the ICL
Pathway 10 day settlement reports.
Automated Payment Service
This is the next automated product after BES, for delivery during ICL Pathway Release
2, for clients other than those of the DSS/ES/SSA(NI).
Award
A decision of entitlement to a benefit, pension or allowance.
Batch
A process by which data is collected at intervals, usually every 24 hours and then sent to
another system in one process overnight.
Batch System
A computer system which is not linked to an on-line system. The information held
cannot be updated on line, but is manually input from a data input form.
Benefit Apportionment System
A computer system that records the details of all payments made that are recorded on the
host business computer system whether paid clerically, or by the system. The details of
these transactions are stored by the payment type and code of issue. Information is
collected from all the business systems that are linked to BAS.
Beneficiary
A person entitled to receive one or more benefits.
Benefit Encashment Service
A service provided and maintained by ICL Pathway to support the encashment of
authorised payments at the PO for Payment Cardholders.
Benefit Payment Reconciliation Panel
A monthly group meeting consisting of members from BA, POCL, COBAP and ICL
Pathway who meet to identify, progress and discuss reconciliation issues which may
affect deliverables in which all parties have an interest.
Business System
The system on which individual business Users record all details relating to the customers
claim and entitlement. This may be an on-line computer system, a system using batch
system processing or a clerical system.
Business Type
COMMERCIAL IN CONFIDENCE Page 8 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref: CS/PRD/0003
BA Reconciliation Process For ICL Pathway sersion: 20 0/98
Release 1c - PART 2 (Resolution)
POCL
This refers to a section within the business system which has an interest in the customer,
e.g. IS, RP, WB or JSA.
CAPS Programme
The Programme to introduce the Customer Accounting and Payments Strategy.
Card
A card or other token to be issued by or on behalf of DSS for the payment of benefits
and allowances and other related benefit and social security purposes, as provided and
managed under the Card Management Service.
Cardholder
A person identified by CAPS as being entitled to hold a card, and to be named on that
card, in order to collect benefit for a specified beneficiary, or a number of specified
beneficiaries.
Card Management Service
A service provided and maintained by ICL Pathway who produce, automate, review,
issue and distribute Payment Cards and Pick-Up Notices.
Card Reader
A device used by the PO through which the Payment Card is swiped. It allows access to
the information held on BES.
Cash Account Period
POCL accounting week which runs from Thursday to the following Wednesday.
Casual Agent
A person authorised by the Beneficiary or Appointee to collect benefit on his or her
behalf on a one-off basis.
Clerical Payment
Any payment that is non-system generated, such as clerically issued order books,
girocheques, payable orders and in some cases, cash.
Clerically Processed Cases
Cases which are assessed and processed manually, although payment can be made on
CPCS provided an account exists on PDCS.
COLS
A dedicated team within the CAPS environment who provide live support
duties for the CAPS systems and CAPS customers.
Commit
In relation to a Transaction, to execute a Transaction Committal for that Transaction.
Related terms shall be construed accordingly.
Computer Support Officer
A nominated individual who controls and supports access to mainframe systems, ensuring
that security and integrity are maintained, liaising with various areas (PID stockholder,
COMMERCIAL IN CONFIDENCE Page 9 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
Security Specialist, DEX, etc.) when appropriate.
Counter Node
See Encashment Reference.
Curator Bonis
A person authorised by the Scottish courts to act on behalf of the customer.
Customer
A person transacting, or seeking to transact business with either AUTHORITY through
any of the Services.
Customer Payment Computer System
It is through this system that Payment Card payments are administered. CPCS holds
details of all payments for all benefits, regardless of the MOP and forwards accounting
details to PACS.
Customer Session
A set of contiguous Transactions recording business transacted by a single
Customer.
Data
Information stored electronically in a database.
Data File
A set of electronic data, contained within a single file and held or used within, or
transmitted over, any of the Services.
Death Arrears Payee
A person accepted by the Secretary of State to receive outstanding amounts of payments
upon the death of a customer.
Deduction Component
An amount deducted from a particular payment component to repay a loan/debt or an
amount deducted for payment to a third party.
Dialogue Expert
A nominated individual who provides advice and guidance to Users with complex cases
or suspected system faults, raising incidents where appropriate. In addition, they provide
liaison between various expert domains, Users and advice lines, etc.
Earliest Encashable Date
The earliest date that a payment can be cashed at the PO. This may be earlier than the
due-date if an adjustment has been made to allow for a Bank or Local Holiday.
Early Batch
Functionality to issue a request in a batch file from a business system which will ensure
that payment/stop will be available on the next working day.
Encashment
COMMERCIAL IN CONFIDENCE Page 10 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
The act of collecting payment(s) for one beneficiary from a PO.
Encashment Identification
A means of uniquely identifying an individual encashment.
Encashment Reference
Following a system failure, a manual BES payment receipt is produced with a unique
number, made up of 18 characters the first of which are 2 spaces;
FAD Code (6 characters) - Identifies the PO at which the encashment was made.
Counter Node (2 characters 00 or //) - The counter position where the encashment was
made.
Sequential Taxation ID (8 characters) - Unique number given to the PO clerk by the
HelpDesk.
Entitlement
The details of the award of a benefit, pension or allowance.
Electronic Point Of Sale Service
A term used to describe the systems typically used in retail shops and stores,
at the point of customer service, for recording sales transactions.
Expiry Period
The period beyond which Payment Cards and payments are no longer valid.
Extended Verification Procedures
Part of the card verification method requiring extra interactions in order to provide a
greater degree of confidence in confirming the identity of a Cardholder.
Exceptions
Any action different from the normal business processing.
FAD Code
See Encashment Reference.
Fall-back
ICL Pathway term for contingency.
File
A means of transferring data from one system to another. Each file generally consists of
a standard header, a series of detailed records and a specific trailer.
Foreign Encashment
An encashment of an Authorised Payment which occurs at a post office other than the
Nominated Post Office.
Help Desk
The initial point of call for Users in need of support relating to the services.
COMMERCIAL IN CONFIDENCE Page 11 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
Horizon System HelpDesk
A technical help desk provided by ICL Pathway.
Host Business System
The business system through which CPCS and PDCS are being accessed.
Improper Encashment
An encashment that has been made to a person not entitled to the payments received.
Incident
Any perceived abnormal or undesirable occurrence relating to a Service.
Incident Resolution
The agreed closure of an Incident which may include the re-establishment of Service
following an Incident or, where the Incident was found not to be an abnormal or
undesirable occurrence, clarification of the incorrect perception
Incident and Problem Management System
A dedicated ITSA system which enables DSS Expert Domains to log incidents and
problems and maintain an accurate and ongoing review process from logging to
resolution.
Lisahally
Lisahally is the location of the Paid Order Unit who provide payment receipt storage,
search and retrieval services for the Agency or ES. The payment receipts are sent by the
PO for secure storage, so that they remain accessible to the Agency or ES on request.
Main Payee
For certain business systems (e.g. Child Benefit), two people are equally eligible for
collection: the customer and his/her spouse or partner. Sometimes the customer is also
referred to as the Main Payee.
Method of Payment
The form of payment recorded against a Transaction involving a Customer.
Node Id
See Encashment Reference.
Nominated PO
A specific post office at which a Beneficiary has elected to receive benefit payments.
On-Line Day
The period of time during which a computer system is available for use each day.
One Off Payment
A Payment Instruction that contains only one Like Payment which consists of one
Authorised Payment.
Other Guardian
A person appointed by the courts in Scotland to act on behalf of the customer.
COMMERCIAL IN CONFIDENCE Page 12 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
Other Payee
A person who, in certain circumstances, the customer may elect, or have elected for
them, to collect payments on their behalf.
Parent/Guardian
Specifically the parent or guardian of a child who has been awarded DLA or WPA. The
parent/guardian acts on behalf of the child, regardless of whether the child is capable of
managing their own affairs.
PAS Exception
A transaction received by CPCS from PAS contained in an Encashment file is matched
against the customer record held in CPCS. Where one or more data item(s) do not
match exactly with the corresponding data item(s) on the Authorised Payment record(s)
held upon CPCS, an Exception (and report) is Produced. The Exception must be
investigated to allow the correct updating of CPCS.
Payee
The person who is entitled to collect payments, (customer/PAB/alternative payee or
agent).
Payment Advice Notes
Leaflets sent to the customer containing information and advice such as reporting
changes of circumstances to the Agency or ES. These will replace the Yellow Pages
currently found at the back of the order book.
Payment Authorisation Service
A service provided and maintained by ICL Pathway for the management of payments
authorised for collection by customers or their representatives.
Payment Card Help Line
A telephone service provided by ICL Pathway covering Card Management Service
(CMS) helpdesk and Payment Authorisation Service (PAS) helpdesk. This area acts as
the single point of contact for all enquiries relating to Payment Cards and PUNs
Separate telephone numbers are used by the DSS, POCL and the public (one number is
also dedicated to Welsh speaking customers).
Payment Component
The breakdown of a payment into its component parts, e.g. basic rate, age related
addition, additional components etc.
Payment Due Date
The date that payment is due to the customer, as authorised by the Agency or ES.
Payment Instruction
An instruction from a business system or clerically input to CPCS, that contains all the
information necessary to allow CPCS to authorise the issue of payments to the correct
person, at the correct rate and at the correct time.
COMMERCIAL IN CONFIDENCE Page 13 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
Permanent Agent
A person authorised by the Beneficiary or Appointee to collect benefit on his or her
behalf (until revocation of that authorisation).
Payment Receipt
A prepared slip completed during encashment at the outlet counter to provide details of
the beneficiary’s authorised payments.
Payment Request
The action taken by a User to ask a business system to pass a Payment Instruction to
CPCS.
Personal Acting Body
Someone who acts on behalf of a customer for the Agency and ES business. In effect, the
PAB then becomes the customer, in that they are responsible for signing declarations and
reporting any changes of circumstances on the customers behalf, e.g. an appointee.
Personal Details Computer System
The computer system through which personal details relating to a customer and, where
appropriate, other payees are input and maintained.
Pick-Up Notice
Notification to an Authorised Person that a card is ready for collection by him or her.
Power of Attorney (Enduring)
The appointment of an agent by deed, which if specified by that deed, can for the
purposes of the Agency or ES transfer responsibility from the customer to the Attorney
in relation to all matters concerning receipt of payments and are legally allowed to
manage the customers affairs without time limitation. It can be terminated by the death
of a customer or attorney, or in the event of customers bankruptcy.
Power of Attorney (Limited)
Is legally contracted to manage the affairs of the customer. Must be granted specific
powers by the court to handle the customers financial affairs, but may not act for the
customer without the Secretary of State granting them powers to deal with the customers
affairs under the BF56 procedure. The appointment may be limited by time and/or
purpose. It can be terminated by the death of the customer or Attorney, the customer
becoming bankrupt, or the customer losing the capacity to manage their own affairs.
Qualified NINO
A NINO allocated where we have established the customers identity but require to carry
out final corroboration. The qualified NINO has time controls in place to ensure the
necessary follow up action is carried out and can only be allocated if benefit is due.
Reconciliation Exception Database
ICL Pathway Customer Services database which will hold details of all reconciliation
exceptions relating to benefit encashments made via the BPS, identified by themselves,
DSS/ES/SSA(NI) or POCL.
Record
COMMERCIAL IN CONFIDENCE Page 14 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref: CS/PRD/0003
BA Reconciliation Process For ICL Pathway sersion: 20 0/98
Release 1c - PART 2 (Resolution)
POCL
A unit of information. Several records make up a file.
Restricted PO
A Restricted Post Office is a designation used to describe a situation where an
Authorised Person must use their Nominated Post Office to encash Authorised
Payments.
Royal Mail Address
An address which is in England, Scotland, Wales, Northern Ireland, the Isle of Man or
the Channel Islands (Jersey, Guernsey, Alderney and Sark).
Seal of Approval
A key Information System Policy of the DSS, which aims to ensure that all deliverable
end products are provided once all issues and non-conformities have been addressed.
This provides assurance to Accountable Officers that a quality product is delivered with a
guarantee of “fit for purpose”.
Sequential Taxation Id.
See Encashment Reference.
Service Architecture Design Document
The document showing the Service Architecture developed pursuant to Clause 401.1.1,
as amended from time to time to reflect optional and additional Products and Services
supplied and performed under the POCL Agreement and the DSS Agreement.
Service Code of Practice for Help Desks
Describes the services involved in the Card Payment environment for Release Ic, their
roles, responsibilities and the way they interact. Also describes the generic procedures
for incident and problem management.
Service Level
A quantified and measurable standard, as defined in the Related Agreement, required
for a specified Service.
COMMERCIAL IN CONFIDENCE Page 15 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
Signing Agent
An official of the Local Authority who is authorised to deal with all the residents
payment, e.g. a warden. A signing agent is only appropriate for customers who are in
Local Authority Part III Residential Accommodation.
Standing Agent
A person nominated by the customer with prior agreement of the Agency or ES who
may, on a long term basis, collect any payments on behalf of the customer.
Stop Request
An instruction released by a business system to CPCS to stop a payment.
Superseded Account
The account which has been closed by the appropriate User. This account is held for
historical purposes only and may be viewed but not maintained.
Superseding Account
An account which has replaced another for the same customer under a different NINO.
The account is fully maintainable using existing CAPS facilities.
Swipe
The action of passing the Payment Card through the Card reader at the PO.
System Support Centre
ICL Pathway technical support services.
Temporary Token
A token that permits an Authorised Person to encash one or more Authorised Payments.
Temporary Token PO
To collect payment(s) using a TT the customer/Alternative Payee/Death Arrears
Payee/PAB can specify a PO to use the TT at for collection of payment. This PO must
be used for all encashments made using the TT.
Third Party Deduction
An amount deducted from a payment component that is specifically for payment to a
third party on the customers behalf, e.g. payments of electricity or gas.
Transaction
A recorded and auditable instance of business activity, involving Service provision or
Stock movement across organisational or Service boundaries.
Transitional Period
The time from when the first customer is migrated to PDCS until customers of all
business systems are accounted for under CAPS.
Tripartite
A three way partnership between ICL Pathway, DSS/ES/SSA(NI) and POCL.
Tutor
COMMERCIAL IN CONFIDENCE Page 16 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway Version: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
A person appointed by the courts in Scotland to act on behalf of a customer.
Unsafe Address
Where a record of continual loss of IOPs and PUNs is held relating to that particular
address.
Urgent Payment
An Authorised Payment that must be available for collection at a post office within 30
minutes of its authorisation by CAPS.
Urgent Stop
A stop request issued immediately to the post office and the result notified immediately to
the post office clerk on-line and the business system. This stop request is actioned via a
CPCS on-line dialogue
User
A person authorised by the relevant AUTHORITY to use a Service.
Voice Bank
An automatic system for receiving and directing information.
Void Transaction
A Transaction which is cancelled before Transaction Committal.
COMMERCIAL IN CONFIDENCE Page 17 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
0.6 Changes in this version
This document covers the handling of Customer Payment for Child Benefit
customers only. Part 2 (Resolution) for Pathway Release 2 will contain Customer
Payment Query Process Models for all other Benefits, including Centralised and
District based Benefits.
0.7 Table of content
1 Introduction 21
2 Scope 21
3 Purpose 22
4 Approach 2
5 Key Principles For Resolution 23
6 Principles For The Resolution Of Reconciliation Incidents 24
6.1 Resolution Of Customer Payment Queries Where Customer
Does Not Have APayment Receipt 24
6.2 Resolution Of Customer Payment Queries Relating To
Entitlement/Non Receipt Of Benefit Payment 26
6.3 Resolution Of Outward Leg Data Errors In Normal Operations/
Customer Payment Queries 27
6.4 Resolution Of Return Leg Data In Normal Operations 30
6.5 Resolution Of Fall-Back Payment Errors Involving Manual Payment
Receipts/Customer Payment Queries 31
6.5.1 Before the end of the cash account period 31
6.5.2 After the end of the cash account period 32
6.6 Resolution Of Lost Transaction Data In Normal Operation 32
6.7 The Reconciliation Exception Database (RED) 34
6.8 Investigations 34
6.9 Clearance and Closure Criteria for RED Incidents 34
7 DSS Reconciliation Resolution - Process Models And Resolution Of
Customer Payment Queries 35
7.1 Customer Underpaid - refused payment (void payment receipt) 36
7.2 Customer Underpaid - received payment (automated payment receipt) 41
7.3 Customer Underpaid - received payment (manual payment receipt) 46
COMMERCIAL IN CONFIDENCE Page 18 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref. CS/PRD/0003
BA Reconciliation Process For ICL Pathway version 20 0/98
Release 1c - PART 2 (Resolution)
POCL
7.4 Customer Underpaid - no payment receipt 53
7.5 Customer Due Payment - nil payment receipt 60
7.6 Customers Who Have Been Overpaid 65
8 ICL Pathway Reconciliation Resolution 68
8.1 Generic Process Models of ICL Pathway Reconciliation Resolution 68
8.2 Overview of Generic Process Model of ICL Pathway Reconciliation 7
8.3 Supporting Services Provided to the BSU, Roles, Responsibilities and
Dependencies 74
8.4 Link Between RED Incidents and Resolution Actions 7
8.5 Attempt Correction of System Records in Conjunction With PCHL 78
8.6 Resolution Actions 79
9 Post Office Reconciliation Resolution 85
9.1 Offer By Customer To Return Money When Payment Errors Have Been
Made In Fall-Back (Transcash) 85
10 Recovery Of Receipts From Lisahally 87
10.1 Process Models 88
Appendix A - Repudiation
Appendix B - Inactivated Cards
90.
94
COMMERCIAL IN CONFIDENCE
Page 19 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref: CS/PRD/0003
BA Reconciliation Process For ICL Pathway sersion: 20 0/98
Release 1c - PART 2 (Resolution)
POCL
1 Introduction
Benefit Payment Reconciliation Processes for ICL Pathway Release Ic are divided into seven
parts. Part 1 deals with reconciliation incident management. This part (Part 2) describes
reconciliation resolution processes. Part 3 focuses on liability assignment. Part 4 defines the
interactions with service and problem management. Part 5 describes the interactions with fraud
management. Part 6 defines the ICL Pathway Reporting Adjustment process which, forms part
of the DSS/ICL Pathway financial controls. Part 7 describes contingency arrangements for
reconciliation.
The end-to-end reconciliation incident management processes described in Part 1
(CS/PRD/0002) define how ICL Pathway, DSS and POCL work together at ICL Pathway
Release Ic to:
e handle customer payment queries and system generated reconciliation reports;
© capture reconciliation incidents;
© progress reconciliation incidents to the point of resolution.
This document supplements the information given in Part 1 and describes how ICL Pathway,
DSS and POCL work together to:
e resolve any benefit under or overpayments;
¢ resolve BPS transaction data exceptions in the return leg (BES to PAS and thence CPCS (for
DSS) and ABED (for POCL)).
The models contained within this document provide a framework for the development of local
procedures and their integration.
It is planned to maintain the process models contained within this document under change
control for the duration of ICL Pathway Release Ic and to develop further models to support
future releases.
2 Scope
The scope of this document is restricted to ICL Pathway Release Ic and BPS related
reconciliation. Included within this document are process maps for the resolution of customer
payment queries for Child Benefit.
Included within the scope are:
© the resolution of benefit related under or overpayment incidents;
© transaction data correction - the resolution of return leg errors (BES to CPCS);
Note: At ICL Pathway Release Ic transaction data exceptions in the outward leg (CPCS to BES)
are not corrected.
COMMERCIAL IN CONFIDENCE Page 20 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
The scope excludes:
Th
oe
incident management;
all aspects of assignment of liability;
ICL Pathway/DSS/POCL settlement adjustments in response to tripartite liability
assignment;
fraud management;
problem management;
contingency and reporting adjustments.
Purpose
To define a process framework for the resolution of BPS related reconciliation incidents.
To support the development, enhancement and validation of local procedures.
To inform the BA Security, BA Banking and Accounting Branch SOA process.
Approach
approach used in Part I was continued for Part 2, i.e.
joint ICL Pathway/BA/POCL development, publication and ownership of a set of
reconciliation process definitions covering the scope of this document;
process definitions developed by a process team comprising nominees from ICL Pathway,
BA and POCL, working in conjunction with nominees from the relevant business
organisations;
progress reviewed by the BPS Reconciliation Panel;
process definitions signed-off by senior management in ICL Pathway, BA and POCL;
process definitions maintained under change control for the duration of Release le and
revised to accommodate approved continuous improvements.
COMMERCIAL IN CONFIDENCE Page 21 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref. CS/PRD/0003
BA Reconciliation Process For ICL Pathway sersion: 20 0/98
Release 1c - PART 2 (Resolution)
POCL
5 Key Principles For Resolution
The following principles were used in the design of the Release lc reconciliation resolution
processes. Changes to the key principles would necessitate review/revision of the reconciliation
resolution processes. The principles for reconciliation incident management, liability assignment,
links with problem/fraud management, reporting adjustments and contingency are defined in the
document parts 1, 3, 4, 5, 6, and 7.
© The Reconciliation Exception Database (RED) provides an audit trail for the resolution of
individual transaction (record) errors that occur within the ICL Pathway domain.
¢ Post offices resolve all issues relating to payment against a receipt, e.g. receipt states £15,
customer claims that more or less money was handed over, in accordance with normal post
office working practices. RED incidents are not raised in these situations.
e Post offices attempt to resolve, in conjunction with the PCHL, customer payment queries
relating to fall-back operation (indicated by a manual receipt) that are made during the current
cash account period, provided the customer queries payment at the post office where the
original payment was made. RED incidents are not raised in these situations.
e DSS (CBC/DO) offices resolve customer misunderstandings relating to entitlement or
payment.
e ICL Pathway write and issue cheques for confirmed underpayments made in fall-back, subject
to being given the go ahead by the central DSS contact point, ie. DSS COLS Business
Support.
e The DSS resolve all automated payment queries. For confirmed automated payment errors
(under and overpayments) and confirmed fall-back overpayments ICL Pathway pass
information to the central DSS contact point, i.e. DSS (COLS), for onward communication to
relevant DSS resolution authorities.
e RED incidents may be escalated to ICL Pathway Problem Management if it is agreed that the
RED incident forms part of a wider problem that is being managed by ICL Pathway, POCL,
DSS. RED incidents may be cleared at this point and held in the cleared state until closure
information is provided by the appropriate Problem Management authority.
e RED incidents may be escalated to ICL Pathway Fraud Management if it is agreed that the
RED incident forms part of a fraud incident. RED incidents may be cleared at this point and
held in the cleared state until closure information is provided by ICL Pathway Fraud
Management
COMMERCIAL IN CONFIDENCE Page 22 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
6 Principles for the Resolution of Reconciliation Incidents
The organisation responsible for actioning the resolution is shown against each principle and
cross referred to the Incident Management (IM) Principles in Part 1.
The post office resolves any normal dispute with the customer as per their current instructions.
Lower level process models covering the handling of customer payment queries in the DSS
(CBC/DO) can be found at Para 7 et seq.
It is acknowledged that the repudiation process, i.e. where the customer disputes receiving an
encashed payment, could be triggered in every scenario and therefore is not listed in every
instance to prevent the document becoming over elaborate. However, process maps covering
repudiation can be found in Appendix A.
Resolution Principles are prefixed R.
6.1 Customer Payment Queries Where Customer Does Not Have a
Payment Receipt
Post offices attempt to resolve a customer payment query where the customer does not have a
payment receipt, but there would need to be a good reason, e.g. post office clerk is aware that
the system has been down or remembers the customer. However, in general, customers without
a payment receipt are routed to the DSS (District Office/Child Benefit Centre). The District
Office/Child Benefit Centre may well ask the customer to make a signed statement in these
circumstances. The decision whether or not to request a copy of the payment receipt from
Lisahally rests with the DSS.
Overpayment processes can be found at Para 7.6
Ref. Reconciliation Resolution Principle Action By
RI Scenario: Customer without a payment receipt queries payment and the I POCL
information provided by the customer indicates that the customer has
returned to the post office where the original encashment was made, that
x ref I it was a fall-back encashment and it is before the end of the cash account
IMI1 period.
Action: Post office ATTEMPTS to resolve the payment error by trying to
retrieve original receipt, If unsuccessful the customer is referred to the
DSS.
R2 Scenario: Customer without a payment receipt queries payment and the I POCL
information provided by the customer indicates that the query does NOT
relate to a fall-back encashment at the original post office within the
xref I current cash account period.
IM12 Action: Post office advises the customer to contact the DSS.
R3 Scenario: Customer phones the PCHL before or afier the end of the cash I ICL Pathway
xref account period and queries payment but does not have a payment receipt.
IMB Action: The PCHL advises the customer to contact the DSS.
R4 Scenario: Customer without a payment receipt queries payment at a DSS I DSS
office before or after the end of the cash account period.
Refer to process
COMMERCIAL IN CONFIDENCE Page 23 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get - SB/PRDIO008
Reconciliation Process For ICL Pathway Version: 2.
BA ,
Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
xref I Action: DSS checks entitlement/payment and resolves any customer I maps at para 7.4
rug _ I misunderstanding. See RS and R6
e If this does not eliminate the query then DSS attempts to establish
whether the encashment occurred in fall-back or normal operation
(this may require a telephone call to PCHL).
e If CPCS/FBS or PCHL confirm underpayment during normal
encashment then underpayment is corrected by using an “Alternative
Method of Payment”. See Para 7.
e If the encashment is shown to have occurred in fall-back the DSS
provides the customer with transaction reference ID and date of
encashment. The customer should then be advised to telephone the
PCHL to report error.
e The PCHL will provide a “customer payment enquiry reporting
service” for customers with manual payment receipts by taking details
ona pro-forma and passing this information to ICL Pathway Business
Support.
ICL Pathway send Cashcheques to make-up underpayments to the
customer’s latest PUN address as notified by CPCS to CMS/PAS. PCHL
confirm customer’s address over the phone afier use of EVP. ICL
Pathway will check with COLS Business Support and the PO before
issuing the cashcheque to ensure that DSS have not already issued
payment.
If the customer fails EVP (perhaps because of a change of address) the
customer should be referred to DSS as per existing procedures for failure
of EVP. No Cashcheque can be issued at that time by ICL Pathway.
If customer passes EVP but notifies change of address to PCHL. PCHL
will pass new address details to BSU and advise customer to notify DSS
of the change of address. BSU await confirmation of address from CPCS
before issuing Cashcheque. [although’ secure, this process appears to be
far from ideal].
COMMERCIAL IN CONFIDENCE
Page 24 of 95
ICL Pathway Benefit Payment End to End
BA Reconciliation Process For ICL Pathway
Release 1c - PART 2 (Resolution)
POCL
FUJ00058360
FUJ00058360
Ref: CS/PRD/0003
Version: 2.0
Date 14/09/98
6.2 Resolution of Customer Payment Queries Relating to Entitlement/Non
Receipt of Benefit Payment
Ref. Reconciliation Resolution Principle Action By
RS Scenario: Customer payment query at a DSS office.
Type of payment receipt: Any type.
xref Action: The DSS office investigates and resolves any customer I DSS
IMI-3. misunderstanding relating to payment/entitlement.
e.g. customer has gone too early to the PO or there has been a recent
change in entitlement.
e A User may raise a business incident if procedures or information is
found to be incorrect/misleading or have not been followed.
R6 Scenario: Customer claims they have not received payment or no
payment was available.
xref .g. payment card has not been correctly activated by the PO, payment has
been cancelled, payment instruction has failed to reach CPCS.
IMI Type of payment receipt: Nil or none. Dss
Action: The DSS office decides whether to raise an incident with COLS. I Refer to process
maps at paras
Activation of the card process maps can be found at Appendix B. 7.4 and 7.5
Example
Notification of
>
Entitlement to Outward Leg
Customer PACS
bP I
+ I
FBS PL ad PAP —eI Payment
CPCs E PAS E BES to Customer
it ld
Return Leg
=<
COMMERCIAL IN CONFIDENCE
Page 25 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
6.3 Resolution of Outward Leg Data Errors in Normal
Operation/Customer Payment Query
In exceptional circumstances transaction data errors may occur within a system or
between systems.
Ref. Reconciliation Resolution Principle Action By
R7 Scenario: Data corruption within CPCS or between FBS and CPCS. See
5 example below.
xref
IMI-3 Type of payment receipt: Void or Normal Automated Receipt.
How detected: Difference between notified payment/entitlement and
encashment, leading to a customer payment query at a DSS office and the
DSS raising an incident via COLS.
Action: DSS
© If customer doesn’t accept payment at PO (unsigned/signed void I Refer to process
payment receipt), DSS stop payment in FBS and re-issue payment. maps a spares
and 7.
e If payment cashed (see example below) DSS will correct
underpayment by using an “Alternative Method of Payment”, See Para
7
© The DSS (on behalf of the Secretary of State) will consider recovery of
overpayments (Process under development - See Para 7.6
Example
>
Outward Leg
PACS
£5I)DP
EI£5
AP £5 AP £5 £5
£50 CPCS >I >
FBS te] ¢5 PAS [TMSIBES > Payment
PI bq E £5} bgE £5 I to Customer
Return Leg
~<«
COMMERCIAL IN CONFIDENCE
Page 26 of 95
ICL Pathway
BA
POCL
Benefit Payment End to End Ref:
Reconciliation Process For ICL Pathway _ Version:
Release 1c - PART 2 (Resolution) Date
FUJ00058360
FUJ00058360
CS/PRD/0003
2.0
14/09/98
Ref.
Reconciliation Resolution Principle
Action By
R8
x ref
IMI -3
Scenario: Transaction data error in the “outward leg” (between CPCS
and PAS or within PAS) before encashment, resulting in the encashment
not matching the Authorised Payment. See example below.
Type of payment receipt: Void or Normal Automated Receipt.
How detected:
© Difference between notified payment entitlement and encashment
leading to a customer payment query at DSS office.
© Mismatch between AP and E in CPCS and DP and E in PACS. PAS
exception is created on CPCS database. RED report not initiated as
no mismatch within PAS. However, if root cause is found to be in ICL
Pathway then COLS will raise an incident on HSH and RED report
produced.
Actions:
© Ifcustomer refuses payment at PO (unsigned or signed void payment
receipt) DSS (via COPS Adviceline) confirms payment uncashed.
DSS will advise customer to return to the PO to collect the payment
available and correct any underpayment by using an “Alternative
Method of Payment”. The corrupted payment cannot be stopped via
CPCS. The amount held in CPCS does not match that in PAS and
therefore PAS validation would reject the stop request.
© CPCS User will see the AP(s) flagged as exceptions. COLS will have
raised an incident on PAS Exception. (From CAPS Rel 4 more details
of improper encashments will be shown on CPCS)
© BAB will have to take corrective action to amend PACS.
© The DSS (on behalf of the Secretary of State) will consider recovery of
overpayments. (Process under development - See Para 7.6)
DSS
Refer to process
maps at paras
7.1 and 7.2
Example
a
Outward Leg
PACS
£501DP Exception details are received mannually until CAPS Rel 4.
E}£
nr
PI
~=t
Return Leg
cpcs 2%] pas -APtinI £5
FBS [£0 , £50 £5 IMsIBES I Payment
eis I jwq—E tS} to Customer
COMMERCIAL IN CONFIDENCE
Page 27 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref. CS/PRD/0003
BA Reconciliation Process For ICL Pathway sersion: 20 0/98
Release 1c - PART 2 (Resolution)
POCL
Ref. Reconciliation Resolution Principle Action By
RO Scenario: Transaction data error in the “outward leg” (between PAS and
BES or within TMS/BES) before encashment, resulting in the
encashment not matching the Authorised Payment. See example below.
x ref
IMI -3
Type of payment receipt: Void or Normal Automated Receipt.
How detected:
© Difference between notified payment entitlement and encashment
leading to a customer payment query at DSS.
¢ Mismatch between AP and E in PAS and CPCS, and DP and E in
PACS. PAS exception is created on CPCS database. Mismatch
detected within ICL Pathway by PAS and RED incident raised. COLS I DSS
will raise reconciliation incident. Refer to process
maps at paras
Actions 7.1 and 7.2
¢ Transaction data errors are not corrected because the encashment
information reflects what was actually paid to the customer and
ABED and cash account data (from BES reports) are aligned.
© CPCS flags the Encashment and Authorised Payment(s) concerned as
PAS Exceptions. The encashment record is suspended and copied
back to PAS, but no action is taken and exceptions will accumulate
until a potential change to CPCS in CAPS Release 4 (or later).
¢ CPCS users will see the AP flagged with the status “Exception”
within the appropriate CPCS dialogue and will contact COLS for full
information.
¢ The DSS will correct underpayments by using an “Alternative Method
of Payment”. See Para 7.
The DSS (on behalf of the Secretary of State) will consider recovery of
overpayments. (Process under development - See Para 7.6
© RED report explains error in the outward leg and confirms
underpayment.
Example
Outward Leg
PACS
£50) DP
EI £5
spesn apes £5
rps. I £50 nso ms I'MsIBES I} Payment
PI «Ess I jxq—EtS {£5 I £5 to Customer
Return Leg
=
COMMERCIAL IN CONFIDENCE Page 28 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
6.4 Resolution of Return Leg Data Errors in Normal Operation
Reconciliation Resolution Principle Action By
R10
x ref
IMI -3
Scenario: Transaction data error in the “return leg” (after encashment),
resulting in the reported encashment not reflecting what was actually paid
to the customer. Note that errors may either be common to both the
CPCS and ABED streams or may apply only to one or the other. Errors
in the CPCS stream will mismatch against the Authorised Payment(s).
Errors in the ABED stream will not be detected unless a cash account
error is produced later in the process.
How detected: Mismatch between AP and E in CPCS or PACS leads to a
COLS or BAB raised reconciliation incident. Mismatch also detected
within ICL Pathway by PAS. (See example below) Subsequent ICL
Pathway investigation in response to a HSH reconciliation incident
identifies whether the error was in the outward leg or the return leg. For
outward leg errors the ICL Pathway investigation also identifies what was
actually paid to the customer.
Actions to correct the CPCS stream:
¢ Errors in the return leg will be corrected to make reported encashment
information match what was paid to the customer.
suspended and copied back to PAS.
¢ Errors will be amended by ICL Pathway and returned to CPCS in the
normal stream.
* Corrected errors will be matched against the Authorised Payment(s) to
clear the exception.
Actions to correct the ABED stream:
¢ ICL Pathway will include the error and the correction amount in a
special RED report. Report to include: total encashment for date
dd/mm/yy were £X and corrected encashments were £Y.
e POCL will use the report to key corrections to ABED or CBDB
depending on timing. The post office account BES line will then
match the amended ABED/CBDB figures.
Example
Outward Leg
PACS
£50] DP
EI£5
PI
cpecs [APS pas PAPE £50
FBS. I_£50 [TMSIBES > Payment
£50 I ces I £50 IQ pes I 50] £50 to Customer
~t
6.5 Resolution of Fall-back Payment Errors Involving Manual Payment
Return Leg
COMMERCIAL IN CONFIDENCE Page 29 of 95
DSS/ICL
¢ Errors in the CPCS stream will be flagged as PAS Exceptions, Pathway
POCL/ICL
Pathway
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
Receipts/Customer Payment Queries
Transaction data within the DSS, ICL Pathway, and POCL will not be corrected to
reflect fall-back errors. The PO will complete its BES cash account total by adding the
manual payment receipts, which reflect the true encashments.
The POCL ABED system will receive the intended amount from PAS. A mismatch will
be generated if the ABED information disagrees with cash account data. POCL will
check that ABED/cash account mismatch is not already covered by a RED incident and
will raise a HSH reconciliation incident if they are unable to match with an existing RED
incident. CPCS will receive the intended amounts from PAS and this will match the
Authorised Payment. As a result fall-back errors will not be visible on CPCS.
Example
PACS
£50} DP
EI £50
T T
5
. Pp AP £50y, I PA LAP £505, 1
FBS [£50_, I CPCS s rus) Fallback
Pl £50 Es50 I £50 lL
£50
AP/E Committed by
Y PcuL
‘ £5
PCHL +7 PO I» Payment to
Phone Customer
line
6.5.1 Before the end of the cash account period
Ref. Reconciliation Resolution Principle ‘Action By
Ril Scenario: Customer queries payment at the post office in which the
original encashment was made before the end of the cash account period.
xref Type of payment receipt: Manual
1M4-7 I Astion: Post offices attempt to resolve under or overpayments relating to
fall-back errors via interaction with PCHL. POCL/ICL
Pathway
Exception: Principles R12, R13 and R14 will apply if the above is not
successful.
COMMERCIAL IN CONFIDENCE Page 30 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get ; SB/PRDIO008
Reconciliation Process For ICL Pathway Version: 2.
BA -
Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
6.5.2 After the end of the cash account period
Ref. Reconciliation Resolution Principle Action By
Ri2 The PCHL will provide a “customer payment enquiry reporting service” I ICL Pathway
xref for customers with manual payment receipts by taking details on a pro-
forma and passing this information to ICL Pathway Business Support.
IMB8-10
RIB ICL Pathway send Cashcheques to make-up underpayments to the I DSS/ICL
customer’s latest PUN address as notified by CPCS to CMS/PAS. PCHL I Pathway
confirm customer’s address over the phone after use of EVP. ICL
Pathway will check with COLS Business Support and the PO before
issuing the cashcheque to ensure that DSS have not already issued
payment.
Refer to process
maps at para 7.3
If the customer fails EVP (perhaps because of a change of address) the
customer should be referred to DSS as per existing procedures for failure
of EVP. No Cashcheque can be issued at that time by ICL Pathway.
If customer passes EVP but notifies change of address to PCHL. PCHL.
will pass new address details to BSU and advise customer to notify DSS
of the change of address. BSU await confirmation of address from CPCS
before issuing Cashcheque. [Although’ secure this process appears to be
far from ideal].
R14 DSS (acting on behalf of the Secretary of State) will consider recovery of I DSS
overpayments. (Process under development - See Para 7.6)
RIS ICL Pathway will operate a Transcash account to receive, across post I POCL/ICL
office counters, any voluntary return of overpayments made in fall-back I Pathway
(but not in normal working).
6.6 Resolution of Lost Transaction Data in Normal Operation
A lost transaction is possible if one of the following system error events occurs mid-way through
a transaction (e.g. after a receipt has been printed, the customer has been paid but the
transaction has not been finished:
« A power failure.
« Anunexpected “system lock” or error message.
Following the commitment of the transaction at the counter, the transaction can be lost prior to
receipt at Pathway. This is indicated by an unexpected “system lock” or error message.
The previous risk of data loss as a result of enforced log out has been eliminated by the
application of a system fix.
Data loss can be highlighted within the post office by comparing payment receipts with a BES
report. Resolution can be triggered if post offices report such observed differences to the HSH.
NB: There is an opportunity for HSH to be proactive following a confirmed hard disk failure by
asking the post office clerk to run a BES report, check recent payment receipts and report any
that are missing.
COMMERCIAL IN CONFIDENCE Page 31 of 95
ICL Pathway
BA
POCL
Benefit Payment End to End Ref:
Reconciliation Process For ICL Pathway —_ Version
Release 1c - PART 2 (Resolution) Date
FUJ00058360
FUJ00058360
CS/PRD/0003
2.0
14/09/98
Example
Notification of
Entitlement to
Customer
PACS
FBS
£50) DP
E/ £50
T T
cpcs IALESMel pag AP£S0pl
ITMSIBES 7?
Ta PT £50 Le reso I £50
Lost
NB: PCHL may not be able to force encashments
if customer attempts to encash before Pathway
are notified by PO that transaction has been lost.
Force “E” £50 to prevent
PCHL lag" po} incident PO
£50
Payment to
Customer
customer being able to encash twice
Ref.
Reconciliation Resolution Principle
Action By
R16
Scenario: Lost transaction within BES.
How detected: Observed mismatch between BES report and payment
receipts at any time, plus proactive action after fixed disk failure in single
counter post office.
Action: ICL Pathway attempt to recover using information from the post
office receipts and dummy encashments via the PCHL to align system
data with the true position.
Exception: If the above action is not possible a hidden duplicate
encashment will occur and ICL Pathway will notify DSS via a RED
incident report. On receipt of the RED COLS will notify ChB of the
overpayment.
ICL Pathway
DSS/POCL/ICL
Pathway
R17
Scenario: Loss of card activation transactions.
How detected: Customer reports no payment available.
Action: See R6, Appendix B.
DSS/POCL/ICL
Pathway
R18
Scenario: Card and/or PUN impound transactions.
Transactions relating to the recording of lost cards are handled by the
PCHL and therefore are not a risk as a result of BES transaction loss.
Customers do not have their original card/PUN after impound, so there is
no risk of card/PUN misuse. However, if a card impound transaction is
lost the customer will be able to report to PCHL and trigger a
replacement. However anyone attempting to use the replacement
card/PUN would hit the same impound trigger. There is no business risk
associated with lost card impound transactions and therefore no special
arrangements have been made.
DSS/POCL/ICL
Pathway
6.7 The Reconciliation Exception Database (RED)
COMMERCIAL IN CONFIDENCE
Page 32 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Get SB/PRDIO008
Reconciliation Process For ICL Pathwa: ersion: 2.
BA atnway pate 14/09/98
Release 1c - PART 2 (Resolution)
POCL
Ref. Reconciliation Resolution Principle Action By
RID The Reconciliation Exception Database (RED) will record and be the ICL Pathway
basis of reporting of reconciliation incidents, investigations and
resolution.
Exceptions: The RED will only include incidents that have been reported
via an HSH Reconciliation Incident. It will therefore exclude
reconciliation errors caused by errors within the DSS systems. These will
be resolved by DSS COLS.
6.8 Investigations
The implications of reconciliation incidents normally extend across the boundaries between DSS,
POCL and ICL Pathway. Therefore it is necessary for all three parties to co-operate during
investigation. The following shows the area of responsibility for each organisation .
Ref. Reconciliation Resolution Principle Action By
R20 The DSS is responsible for investigating errors in CPCS, PACS and the DSS
interfaces with Feeder Benefit systems plus reconciliation implications.
R21 POCL is responsible for investigating errors within ABED, CBDBand POCL
post office cash accounts.
R22 ICL Pathway is responsible for investigating errors within the ICL ICL Pathway
Pathway systems and interfaces (PAS and BES).
6.9 Clearance and Closure Criteria for RED Incidents
RED incidents will be cleared when one of the following is met:
e reconciliation incident resolved, interested parties informed, liability assigned and
settlement invoice date quoted.;
e reconciliation incident passed to fraud and fraud case reference quoted;
¢ reconciliation incident passed to problem management and a problem reference
quoted.
RED incidents will be closed when all aspects of reconciliation and settlement have been
completed.
COMMERCIAL IN CONFIDENCE Page 33 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway Version: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
7 DSS Reconciliation Resolution
The following process maps deal specifically at a lower level of detail, with the handling and
resolution of customer payment queries. The process maps cover;
¢ Child Benefit (ChB) processes where the customer has contacted the Child benefit Centre,
and,
¢ District Offices (DO) processes where the customer has called into the DO querying their
Card Method of Payment (currently only ChB).
Key To Symbols Used In Models
> Event
Process
=] System/User
) Delay
Decision
) End Process
Simultaneous
Process
COMMERCIAL IN CONFIDENCE Page 34 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
7.1. Customer Underpaid - Refused Payment (Void Receipt)
The following process models cover the circumstances where the customer is alleging she/he has
not been offered the correct amount of benefit at the Post Office and has therefore refused the
amount. The PO Clerk will void the receipt and give the customer a copy, referring the
customer to the DSS to deal with the query.
It is unlikely that the customer would walk out of the Post Office with a manual void receipt,
without asking the PO Clerk to recheck his details either by contacting the PCHL again or
viewing the BES screen.
COMMERCIAL IN CONFIDENCE Page 35 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref. CS/PRD/0003
BA Reconciliation Process For ICL Pathway Version: 20 0/98
Release 1c - PART 2 (Resolution)
POCL
UNDERPAID- REFUSED
PAYMENT (VOID RECEIPT)
CUSTOMER AT DSS (DO)
I Is it Card MOP
i ‘query? (ChB)
of Customer Query Current Procedures
[oT r____I
loximmn pos I
I conmercstatrecty I
Lo. 4
Bs pes PP Gio Process 1011
Frag on Tn
Callgek
CSU Views Pyt
Details on CPS30
CHB Request
BOL Hardeopy
6 a\
Lp Hardcopy
Seconds 7
Recent Change?
(CSU Check Award
Details on ChB
System
CSU Telephone DO]
and Advise of
8 Situation
ChB congirms
‘authorised amount
ts different w receip?
COMMERCIAL IN CONFIDENCE
Page 36 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ger SB/PROIO008
iliati ‘ersion: I
BA Reconciliation Process For ICL Pathway Date q4/0a/e8
Release 1c - PART 2 (Resolution)
POCL
Advise Custor
Tsubo Tae Aébise Customer CSU Anange’® To Retum
COPS Advicetine to BE] “Tele, nderpayment be Fy cal Payment I PB] TeCollect Comupted
Request Pat Status Check Pynt Status Made Via LO Amount ad New
Rectified Amount
csoex !! __
Rates teciceat Consider Suspected
Fraud xX
y
See Repudlation Mode
Rectified Amount
COMMERCIAL IN CONFIDENCE Page 37 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref. CS/PRD/0003
BA Reconciliation Process For ICL Pathway Neision: 20 0/98
oc Release 1c - PART 2 (Resolution) ate
POCL
UNDERPAID- REFUSED
PAYMENT (VOID RECEIPT)
(CUSTOMER TELEPHONES DSS (ChB)
autho
fs different to receipt?
; cara yor i 7
Hew ci customer Redirect Cal Process 5
im No
5
BS Action
Sine ~~~ 777 '
expect in this scenario to be void
ip
ber manual or not, signedor not. 1 x
fl
1
COMMERCIAL IN CONFIDENCE Page 38 of 95
ICL Pathway
BA
POCL
Benefit Payment End to End
Reconciliation Process For ICL Pathway
Release 1c - PART 2 (Resolution)
Ref: CS/PRD/0003
Version: 2.0
14/09/98
FUJ00058360
FUJ00058360
FBS confirms
6
IS] csv checks
FBS
coc?
csUTele. ©
COPS Advic
Check Pyrat Status
Pymt Status
csoex ?
Raises Incident
Y
See COPS
Incident Mgt
Model
See Repudiation Mode
COPS Adtviceting
PB Freie. Pca. to Chee
7 ‘See CAPS Generic
Check Entitlement I BB CoC nquity Modet RB
Cashed?
y
TT
Consider Suspected
Fraud
Y
i
Urgent Need
For Payment?
Advise Customer 151
To Return To PO
To Collect Corrupted
Amount and New
Amount
Tz
Advise Customer
Pyt willbe issued to
Home Addkess and
ko Collect Corrupted
Amount ad New
Rectified Amount
COMMERCIAL IN CONFIDENCE
Page 39 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
7.2 Customer Underpaid - Received Payment (Automated Receipt)
The following model covers the circumstance of the customer alleging that they have been
underpaid benefit. The customer will have an automated receipt showing the amount encashed.
COMMERCIAL IN CONFIDENCE Page 40 of 95
ICL Pathway Benefit Payment End to End
BA Reconciliation Process For ICL Pathway
Release 1c - PART 2 (Resolution)
POCL
Ref: CS/PRD/0003
Version: 2.0
Date 14/09/98
FUJ00058360
FUJ00058360
UNDERPAID - (AUTO RECEIPT)
CUSTOMER TELEPHONES DSS (ChB)
Card MOP:
iow ChB Custom
D
Take Noma 3}
¥BS Acion
Y
Redirect Call
wo CSU
7
y
CSU Check Payment
Details on CPS30
es
QR
Urgent
Payment
Requested?
Reaiify Underpyt
Raise Cust_10
Rectified Pyt Will
be Issued to Address
BH 650 Pass Details
to CSODEX
CHAMP
tobe issued via NE
Preparation
i]
of Payment
Do: ‘s
CSOIDEX Raises
Incident
7
[PRR Refer COPS Incident Management Model I inci
COMMERCIAL IN CONFIDENCE
Page 41 of 95
ICL Pathway
BA
POCL
Benefit Payment End to End Ref. CS/PRD/0003
Reconciliation Process For ICL Pathway Neision: 20 0/98
Release 1c - PART 2 (Resolution) ate
FUJ00058360
FUJ00058360
swvait Hardeop)
seconds
ICSU Check Payment
Details on ChB
System
TF
CSU Check Award
Details on ChB
System
-
is Comect
Refer
Change of Cres. Model
COMMERCIAL IN CONFIDENCE Page 42 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref. CS/PRD/0003
BA Reconciliation Process For ICL Pathway Version: 2.0
Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
UNDERPAID - (AUTO RECEIPT)
CUSTOMER AT DSS (DO)
1s Card MOP
7 Query(ChB)? 5
Customer at Receptionist No Resolve Cstomer Ip
Dss Determine Details ge} Post Query as per
OF Query Curent Procedces
+
1
1
n
Benefit Section
Telephone
fattest
line Callback :
7 , (ChB Authorises and
ol Absiaraid ae ee Refer to Local Payment Procedures
y DOtoConfirm tobe made by DO
Underpayment yo Ho eet Undense
‘SU Check Payment
Details on CPS30
DO Advise Cust.”
Revtified Py Will
be issued to Address
Yes
10
CSU Pass Details
No wo CSODEX
6 v
ChB Request I Ifpayment not urgent
ot u
Cot oy CSODEX Raises Ie Refer to COPS Incident Mangement Model
v Incident
Go to Process 13,
COMMERCIAL IN CONFIDENCE Page 43 of 95
ICL Pathway
BA
POCL
Benefit Payment End to End Ref. CS/PRD/0003
Reconciliation Process For ICL Pathway Neision: 20 0/98
Release 1c - PART 2 (Resolution) ate
FUJ00058360
FUJ00058360
Await Hardeopy
seconds
Tr
[cst Check Payment
Details on ChB
System
17
CSU Check Award
Details on ChB
System
CSU Tetephone DO
BS and Advice of I
Situation
Refer
Change of Cres. Model
COMMERCIAL IN CONFIDENCE Page 44 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
7.3. Customer Underpaid - Received Payment (Manual Receipt)
The processes described here are slightly different to the previous models in that the customer
has encashed benefit at a Post Office during Fall-back when the BES system is down or when the
printer for the receipts is not operating.
COMMERCIAL IN CONFIDENCE Page 45 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ger SB/PROIO008
iliati ‘ersion: I
BA Reconciliation Process For ICL Pathway ate q4/0a/e8
Release 1c - PART 2 (Resolution)
POCL
IUNDERPAID - (MANUAL RECEIPT)
“USTOMER TELEPHONES DSS (ChB)
Card MOP?
View ChB Cust
Det t Co
Redirect Call
wecsu
1
DN Suspect human error 1
between PO and PCHL. I
i
i
COPS Advice Line §
Telephone PCHL
fo Confirm Pyrat Detail
Y
CSU Check Payment
Details on CPS30
COPS Advice Line
Tele. CSU to Advise
‘is Different to Re cu
CSU Advis
COMMERCIAL IN CONFIDENCE Page 46 of 95 v
Go to Process 22
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ger SB/PROIO008
iliati ‘ersion: I
BA Reconciliation Process For ICL Pathway Date q4/0a/e8
Release 1c - PART 2 (Resolution)
POCL
DN: Ifcustomer Is not able
to phone or refuses to phone PCHL.
themselves DO/ChB will phone
PCHL on their behalf without
reference to COPS Advice Line vigor vent
COPS Advice Lie SU Advise Customer
‘ 3 ChB Authorises and -
Kcr] lt 0 wo atrise to Phone PCHL To Ananges Local Pym PO" Refer to Local Payment Procedures
of Situation 1S Report Pymt Exror bbe made by DO.
T
Refer to CL Pathway ] CSU Advise Cust
Incident Pyrat Will Be Issued
CSU Pass Details 16] Mgt Model Direct To Address
to COLS
Business Support eT
30 DN: ICL Pathway check
v Pym sted To UDSshave led pment
Customer By [=] before the ise of thelr cheque,
Tse ICL Pathway The DSS contact point is
Refer to COLS BS COLS Business Support
Incident Management Model “]_Raise Incident on
SeePat I Database
COMMERCIAL IN CONFIDENCE Page 47 of 95
ICL Pathway
BA
POCL
Benefit Payment End to End
Reconciliation Process For ICL Pathway
Release 1c - PART 2 (Resolution)
Ref: CS/PRD/0003
Version: 2.0
Date 14/09/98
Await Hardcopy
Seconds
CSU Check Payment
Details on ChB
Suter
See “Urgent Payment Requested
Refer to ICL Pathway Incident
Mat. Model
Customer Able
T
CSU Advises Cust
Phone PCHL and
To VisitPO
iy Cash Week?,
Report Pynt Error
Refer to COPS.
Incident Management
Model
3 7
csupasDetsis He] cs0DEX Raises
‘0 CSODEX Incident
Customer Returns
ToPO
ChB System Yes
Confirms Authorised
Amount is Different
the Receipt? No
Underpayment
CSU Advises =
‘ustomer of Confirmed}
CSU Check Award
Details on ChB.
System
No CSU Advises 24)
Customer That
Pyrat is Correct
al
Retr to CAPS Change of Cires Mode
Urgent Payment
Q@beneser™
Yes
CSU Advise Cust
Pymt Will Be Issued
Disoot To Address
TB Arrange For Py
to be Issued Via NE
DO to Home Adress
KR
ChB Authorises and
Arranges Local Pyrat
Be Made by DO
Refer to Local
Payment Procedures
ee]
'
R
DN: If customer Is not able
to phone or refuses to phone PCHL.
‘themselves DO/CHB will phone
PCHL on their behalf without
reference to COPS Advice Line
DN: Consider telephoning PO
to advise them of customers return,
COMMERCIAL IN CONFIDENCE
Page 48 of 95
FUJ00058360
FUJ00058360
ICL Pathway
BA
POCL
Benefit Payment End to End Ref: CS/PRD/0003
Reconciliation Process For ICL Pathway Version:
Release 1c - PART 2 (Resolution)
2.0
Date 14/09/98
FUJ00058360
FUJ00058360
JNDERPAID - (MANUAL RECEIPT
CUSTOMER AT DSS (DO)
Is Card MOP
T
Customer at sept Interviews Cust
Dss to Determine Details
of Pvt Query
QuersyChB)?
O* Resolve Customer
[>
Payt Query as per
Current Procedures
1
1
I
I
Cent Need I
I yroroct I
: I
I
I
I DN In most DO receptionist
[_witt contact CSU directly
Le
7
Hold
‘on line’calback
es eT
Y
CSU Check Payment
Details on CPS30
to advise them that
P30
Confirms Authorised Amount
's Different to Receipt?
Refer to COPS
Incident Management
Model
+
DN Suspect human error
between PO and PCHL.
Cash Account
‘ Yes
No
‘COPS Advise Line
Tele CSU to A
‘of Situation 5
csutee.po "4
To Advise of
Situation
Ei
CSOMDEX Raises
Incident
. T
DO Advise Cust, To
Return To PO Before
sh Weck
See “Urgent
Paymient Requeste
Go t0 Process 28
COMMERCIAL IN CONFIDENCE Page 49 of 95
ICL Pathway
BA
POCL
Benefit Payment End to End
Reconciliation Process For ICL Pathway
Release 1c - PART 2 (Resolution)
Ref: CS/PRD/0003
Version: 2.0
Date 14/09/98
FUJ00058360
FUJ00058360
Refer to COLS BS
See Part I
Urgent Payment
COPS Advise Line
Tele, CSU to Advise
of Situation 28
DO Advise Customier
(9 Phone PCH To
Report Pymnt Enon
Requested?
y
=
‘CHB Authorises and
Arranges Local Pym t Refer to Local Payment Procedures
‘be muade by DO
ise Incident on
Database 39
Refer toICL Pathway
Incident
Mat Model
DO Advise Cust.
Pymt Will Be Issued
Direct To Address
Pyant Issued To
Customer By
ICH. Pathway
DN: If customer is not able
to phone ot refuses to phone PCHL
‘themselves DO/CHB will phone
PCHL on their behalf without
reference to COPS Advice Line
DN: ICL Pathway cheek
IEDSS have issued payment
before the issue oftheir easheheque.
Bh
The DSS contact point is
COLS Business Support
COMMERCIAL IN CONFIDENCE
Page 50 of 95
ICL Pathway
BA
POCL
Benefit Payment End to End
Reconciliation Process For ICL Pathway
Release 1c - PART 2 (Resolution)
Ref:
Version
Date
CS/PRD/0003
: 2.0
14/09/98
Jwait Hardcopy
Seconds
CSU Check Payment
Details on ChB
Swtem 16
ChB System Yes
Confirms Authorised
Amount is Different
the Receipt? No
CSU Check Award
Details on ChB
Syiem 1
Recent
Change?”
Refer w CAPS
Change of Cites
Model
‘Seo “Urgent Payment Requested’
Refer to ICL Pathway Incident
Customer
To Visit Pe
Report Pymt Eror
Y
Confirmed Underpyin
[CSU Telephone DO
BS and Advise of
Situation
DO Advises Cust
Pymt Will Be Issued
Direct To Address
CHB arrange Tor Pym
tobe issued via NE
DO to customer's
address 23
DO Advise Customer]
That Payrent Is
Correct 19.
‘ChB Authorises and
Arranges Local Pyrat
bbe made by DO
Refer to Local
Payment Procedures
Mat Model Yes
Refer to COPS v
Incident Management Model
Customer Returns
To
7 B
CSU Pass Details He] CSODEX Raises
‘© CSODEX Incident
By
CSU Advises DO Urgent Payment
of Customers QO kequesee? .
DN: If customer Is not able
to phone or refuses to phone PCHL
‘themselves DO/CHB will phone
PCHL on their behalf without
reference fo COPS Advice Line
DN: Consider telephoning PO
to advise them of customers return,
COMMERCIAL IN CONFIDENCE
Page 51 of 95
FUJ00058360
FUJ00058360
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
1A Customer Underpaid - (No Receipt)
The following models detail the processes involved in dealing with customer payment queries
where the customer does not have a receipt. This could either be that she/he has mislaid the
receipt or if no payments were available at the Post Office refused a Nil receipt.
COMMERCIAL IN CONFIDENCE Page 52 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ger SB/PROIO008
iliati ‘ersion: I
BA Reconciliation Process For ICL Pathway Date q4/0a/e8
Release 1c - PART 2 (Resolution)
POCL
UNDERPAID - (NO RECEIPT)
CUSTOMER TELEPHONES DSS (ChB)
Card MOP.
View Ci CustomerI_pyy 3
Details to Confirm Take Normal
1D No FBS Action
Tomer
Telephones
che
Includes establishing
* ype of receipt manual or auto
‘customer has 7
oop’ between PO
Redirect Call
DSS and P'Way ‘diet
“Info acceptable over phone. I
SU Check Payment
Details on CPS30
crs30 7
nn COPS Advise Line
csu Tee. 7
COPS Advice Line [BE]. Tee PH
[confirm Pymt Stat
Pc. Confirm Pymt
Status and wheter
fal-back encash
ChB Request
CBOL Hardcopy
Go w Process 21
COMMERCIAL IN CONFIDENCE Page 53 of 95
ICL Pathway Benefit Payment End to End
Reconciliation Process For ICL Pathway
Release 1c - PART 2 (Resolution)
BA
POCL
Ref: CS/PRD/0003
Version: 2.0
Date 14/09/98
FUJ00058360
FUJ00058360
‘COPS Advice Line
PI 10 Cousirm Norma
Encashment 11
Is AP Ditforent
‘See Repuiation Process
Map
ChB Auth
MI
7
de by DO
Advise
: a
Customer Pyrat Wil
1S Address
Be Issued to Address
Lp csv race des
To CSO/DEX
17
CSODEX Raises
Incident
Refer to
Incident
Model
i Management
If payment not ura
cops
I
I
Page 54 of 95
COMMERCIAL IN CONFIDENCE
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ger SB/PROIO008
iliati ‘ersion: I
BA Reconciliation Process For ICL Pathway ate q4/0a/e8
Release 1c - PART 2 (Resolution)
POCL
Got Pro
Await Hardcopy
ChB System
y
‘SU Advise Cust To}
Phone PCHL
(CSU Pass Details
to COLS
Business Support
Report Error 24
CSU Check Award
Details on ChB
Sysiem 19 COLS BS See ‘Urgent Payment Requested’ as per ‘Manual receipt
Raise Incident on Process map @)
Database 23 Refer to ICL Pathway Incident Mgt Model
Change?
Yes Refer to COLS BS DN: Ifeustomer is not able
Tocident Management {@ Phone or refuses to phone PCL,
Model. See Part 1 themselves DO/ChB will phone
PCHL on their behalf without
See CAPS Change of Cites Mode! reference to COPS Advice Line
COMMERCIAL IN CONFIDENCE Page 55 of 95
ICL Pathway
BA
POCL
Benefit Payment End to End Ref. CS/PRD/0003
Reconciliation Process For ICL Pathway Neision: 20 0/98
Release 1c - PART 2 (Resolution) ate
FUJ00058360
FUJ00058360
UNDERPAID - (NO RECEIPT)
CUSTOMER AT DSS (DO)
bs Card MOP
Quench -
Te T Resolve Customer ae
stort Payt Query a8 pet
Tncludes
a)
been in loop’ between
PO DSS and P'way
I ere
Advise Customer
Benefit Section *
Telephone
ChB CSU
BS Await
Call Back
“SU Check Payment
Details on CPS30
Fall-back
Encashment
(Va PCHL?
csu Tele, 7
COPS Advice Line
‘COPS Advice Line
Tele. PCHL to
[confirm Pyrat Status
7
lect. Contirm Pym
Status and whether
fallback encash
->———_>
ChB Request
BOL Hardcopy
i]
Yes
Obsains
Eneashment details
10
y
COMMERCIAL IN CONFIDENCE Page 56 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref. CS/PRD/0003
BA Reconciliation Process For ICL Pathway Neision: 20 0/98
oc Release 1c - PART 2 (Resolution) ate
POCL
Ip Refer Local Payment Procedures K
Vnderpayment
+ await confirmation of
Refer to COPS
6 7
CSU Passes Details HB] CSODEX Raises [BIH Incident Manage
Incident Model
a
Page 57 of 95
COMMERCIAL IN CONFIDENCE
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref. CS/PRD/0003
BA Reconciliation Process For ICL Pathway Version: 2.0
Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
Tele. CSU With
Deiails of Fallback
Encashiment
Await Hardcopy
1
Jcsu Check Payment
Details on ChB CSU Pass Details CSU Tele DO With
Sysem C018 Pocus oan pack
Business Suppet vis OfFal B
DN: If customer isnot able
ChB Sytem to phone or refuses to phone PCHL.
Cons themselves DO/ChB wil phone 7 =
Aleged Cnlerpexment PCH on their behalf without cousBs ® DO Advise Cut
rue ratte I Raise Incident on ise Cus To
No erence to COPS Advi Database Phone PCHL To
Report Eon
15
CSU Check Award
Details on ChB Refer w COLSBS
Sve Incident Mat Mods! See ‘Crgent Payment Requested a per ‘Manual Receipt
See Pat Process Map
= = Refer to ICL Pathway Ineidet Mt Model
Recent {csv Teleptone DO DO Advise Customey
Change? BS andAdve of I BP] Tint Payments I
Sinanion Const
20
CSU Telephone DO
BS and Advise
Of Sinution
Advise Customer
of Award Change
COMMERCIAL IN CONFIDENCE Page 58 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
7.5 Customer Due Payment - (Nil Receipt)
The following models detail the processes dealing with customers who are alleging that they
should be due benefit payment but none was available at the Post Office. This could be due to
any number of reasons e.g. the PI from the FBS has not reached CPCS. The customer should
have a Nil receipt unless they refused a copy at the Post Office.
One of the reasons for payment not being available at the Post Office , could be that the payment
is ‘marooned’. This could be in CPCS, PAS or TMS. One example could be where the personal
details have not been available on CMS so that the Authorised Payments have not been
converted into their ‘enriched’ form for passing to TMS and distribution to BES. There could be
other forms of ‘marooning’ payments, however further information/investigation needs to be
undertaken before principles for resolution can be agreed. This area will be taken forward within
Part II Resolution for ICL Pathway Release 2 document.
COMMERCIAL IN CONFIDENCE Page 59 of 95
ICL Pathway
BA
POCL
Benefit Payment End to End
Release 1c - PART 2 (Resolution)
Reconciliation Process For ICL Pathway
Ref: CS/PRD/0003
Version: 2.0
14/09/98
FUJ00058360
FUJ00058360
DUE PAYMENT (NIL RECEIPT)
CUSTOMER TELEPHONES DSS (ChB)
Card MOP?
DN Possible lostimarvoned pyt
between CPCS and PAS, although unlikely.
Take Normal I
FBS Adtion
T
Customer Tele services
Establishes Details HE
cus of Customer Query
and1D
7
omer if recently
advised of Foreign Encash limit
1, @
ChB Arrange/Auth
Issue of Local
Payment 17
Urgent Payment
wo CSU
Needed?
“Info acceptable over phone
FF Refer Customer
tRPO
Refer to 16
I Advise Customer cst
I After Each Update
‘on CPCS CPS30
7 COPS hetdew Met —<@-—} Rais ncdent
Model
Checks Pymt
PO Restricted?
Payment Available
tocash?
Determine Re
Stoppedeancell
Caste? y, COPS Advicelne!5I
4
CSU Tele
i LB le. PCHL 10
COPS Adviesline Obtain Pymt Details
See COLS Incident Mat c
Models (System/Business)
Determine Reason
For No Pymt Due an
Advise Customer
Payment
COMMERCIAL IN CONFIDENCE
Page 60 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ger SB/PROIO008
iliati ‘ersion: I
BA Reconciliation Process For ICL Pathway Date q4/0a/e8
Release 1c - PART 2 (Resolution)
POCL
PCHL 19
Establish Whether
Refer to
Repudiation Model 20
o Change PO 25
Cashed?
TCH Sap ry
Payment”? poe) e.contimas * I pe] CSU are
Marooned personal details reissue of payment
held
COMMERCIAL IN CONFIDENCE Page 61 of 95
ICL Pathway Benefit Payment End to End Ref: CS/PRD/0003
BA
POCL
Reconciliation Process For ICL Pathway Version: 2.0
Release 1c - PART 2 (Resolution) Date 14/00/86
FUJ00058360
FUJ00058360
DUE PAYMENT (NIL RECEIPT)
CUSTOMER AT DSS (DO)
Is tt Card MOP
Query (ChB)?
cep
DN In most DO's
receptionist will
contact CSU directly
Advise Cu
of Situation After
Each Update
CSU Checks Pymt
DN ChB will update customer by phone,
rather than wait In DO
Procedures
7
Arrange’ Atahorise
Issue of
Local Pts 45
‘00 CPCS CPS30
Payment Available
tocash?
7
Determine Reason} Yes
A iescoscincet an
Advise Customer } Stoppedicaneelled™
¥
Timing? C/Account FBS an Considers
Reissue
4—
See
Mat Model
COPS Incident
i
Refer to
COLS Incident
Met
Mode!
7
Raise Incident
CSU Tele 4
COPS Advssie FO]
COPS Advi
Tele PC
Obiain Pyrat Details
Urgent Need
Payment Pro
Available?
Requesged” ye
>
Raise Incident
via DEX/CSO
Refer to Local Pymnt
Procedures
COMMERCIAL IN CONFIDENCE Page 62 of 95
ICL Pathway Benefit Payment End to End
FUJ00058360
FUJ00058360
Ref: CS/PRD/0003
Reconciliation Process For ICL Pathway Version: 2.0
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
Repudlation Model
PCHL 19
Establish Whether
2
ml Card Activated
>
Cashed?
By
Foreign Encashment
Limit Reached
Change PO. 23
Payment
Marooned
PCHL Stop Pym
and Confitns
ersonal Details Held
COMMERCIAL IN CONFIDENCE
Page 63 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
7.6 Customers Who Have Been Overpaid
e PO currently have procedures to deal with the voluntary return of overpaid monies
(see Para 9.1).
¢ DSS currently have procedures to deal with overpayments of benefit incurred as a
result of:
e — change in entitlement,
© — official error including system error,
e voluntary offer to repay.
Overpayments generated as a result of system error will be visible within CPCS as a PAS
Exception. If the incident is not resolved within the 10 day settlement period then BA
and POCL will settle on the encashment data from Pathway. However if the error
occurred within BES then this will be excluded from the settlement amount. The DSS
will pursue recovery of the overpayment (see process maps overleaf) due to system error.
Overpayments generated as a result of fallback errors will not be visible in CPCS as
CPCS will receive the intended amounts from PAS and this will match the AP. BA and
POCL will settle on the “intended” amount encashed. ICL Pathway will reimburse
POCL with the overpaid amount incurred as a result of “fallback”.
Current BA policy is not to allow Pathway to request repayment of the overpayments
from the customer. The assumption is for the DSS to request repayment on behalf of
ICL Pathway. The amount returned to ICL Pathway in the liability process will include
any cost to the DSS of collecting the amount on ICL Pathway’s behalf.
The Process maps overleaf will be enhanced in Part II Resolution for ICL
Pathway Release 2 Document to incorporate the processes leading up to the
identification of the overpayment, although they will be similar to the processes in parts
7.1 to 7.5.
All of the above is subject to Policy confirmation, currently being pursued by
COBAP.
COMMERCIAL IN CONFIDENCE Page 64 of 95
Ref:
Version:
CS/PRD/0003
2.0
14/09/98
ICL Pathway
BA
POCL
Benefit Payment End to End
Reconciliation Process For ICL Pathway
Release 1c - PART 2 (Resolution)
FUJ00058360
FUJ00058360
OVERPAYMENT DUE
TO SYSTEM ERROR
Overpayment Over
Recovery Threshold?
Pt Identified BD ‘OPS (COLS) Advis No Write oF
Pas Exception or ChB/DO of OPE on =I
ED Report Details 2
fiom st
CHB /DO Advise
COPS (COLS),
I
Cos (COLS)
Upxlate IPMS 4
LoI
‘COPS (COLS)
Advise
BAB ad BSU
Yes
CHBIDO Ask
‘Customer to Repay
OP 6
Incident Recorded
‘on HSH andlor ITSA (SHD)
rR
customer contacts the DSS to advise they have been overpaid
they are likely to voluntary offer (VO) to repay**. Ifthe customer does not notify
the DSS then the ovenpayment may be highlighted when a PAS Exception is ereated
‘on CPCS and/or RED Report i received from BSU
ChB/DO Advise
Customer Repays? ‘COPS (COLS)
—
cops (co1s) *
Update IPMS
> Cops (COLS)
Advise BAB and
BSU (as approp)
see
Ip initty Process
Maps
Write off 10
BA and POCL settle on encashment data from Pathway unless incident resolved in 10 days, Pursue Recovery?
Accounts adjusted taking into account recovery of O'Ptif appropriate.
TT
S08 Decides to
Require Repayment
Y
‘Continue Normal
FBS Procedures to
Recover O/PL 12
COMMERCIAL IN CONFIDENCE Page 65 of 95
ICL Pathway Benefit Payment End to End Ref. CS/PRD/0003
BA Reconciliation Process For ICL Pathway Neision: 20 0/98
Release 1c - PART 2 (Resolution) ate
POCL
FUJ00058360
FUJ00058360
OVERPAYMENT DUE
TO FALLBACK ERROR
J} sec Liability Process
In previous model
*
ChB/DO Advise 1 ‘COLS (BS) 2
lovPt dentified By BH I cosas) BH Povise BAB ands
Cistomer stoner Repaid 0 of Remyment
COLS (5)
Incident Raed
andon ISH
3 ToLsBD 4
Ore dented by Bees Fe] adisecan.n0
RED COLS (BS) of O/Pt Details
HSH COPS (BS)
Incident Raloed Incident Ratsed
‘on Database
* ‘Likely ifthe customer is contacting the DSS they are VO to repay.
* The amount returned fo Pathway inthe lability process will Include any cost
to the DSS of collecting the amount on Pathways behalf
COMMERCIAL IN CONFIDENCE
Page 66 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
8 ICL Pathway Reconciliation Resolution
Reconciliation resolution within ICL Pathway is managed by the Customer Service Business
Support Unit (BSU). All reconciliation incidents involving individual transaction errors that
occur within the ICL Pathway domain are recorded on the Reconciliation Exception Database
(RED). The BSU is responsible for opening, resolving, clearing and closing RED incidents.
The normal trigger for reconciliation resolution is the receipt within the BSU of a Horizon
System Helpdesk (HSH) raised reconciliation incident (event 1 on the following process
diagram). Secondary triggers (event 2 and 3 on the following process diagram) include
reconciliation incidents reported by ICL Pathway Fraud Management and reconciliation incidents
resulting from Transcash deposits (currently raised if/when a deposit is shown on the ICL
Pathway Bank Statement).
DN: Process improvement opportunity for post offices to raise HSH reconciliation
incidents when Trancash deposits are made - the potential process improvement needs to
be impacted by POCL and ICL Pathway.
DN: Process improvement opportunity for ICL fraud management to raise HSH
reconciliation incidents to replace the current paper-based process.
The BSU depends on other organisations for the provision of resolution information and in some
cases for the application of corrective actions. The achievement of the reconciliation SLA
depends on the timely delivery of the supporting “services”, which are summarised in section 8.3.
DN: Internal ICL Pathway SLAs for the “supporting services” need to agreed in
preparation for Release 2.
A generic process model of the ICL Pathway reconciliation resolution is shown below. This is
followed by a textual description of the process model, information on the organisations that
provide supporting services to the BSU and information on the lower-level processes.
The use of RED incident reports to communicate the reporting adjustments used to compensate
for DSS rejected transaction records is not included in this document - see Part 6 for detail.
8.1. Generic Process Models of ICL Pathway Reconciliation Resolution
(See following pages)
COMMERCIAL IN CONFIDENCE Page 67 of 95
FUJ00058360
See Next Page
FUJ00058360
ICL Pathway Benefit Payment End to End Ref: CS/PRD/0003
BA Reconciliation Process For ICL Pathway sersion: 20 59/08
Release 1c - PART 2 (Resolution)
POCL
Event 1 Valid Reconciliation
Al-Pre-scan I !ncident ? [AZ Update HSH
HSH Recon. reconciliation No. incident record
Incident Received incident and/or route back
Within the BSU Yes to originator
Event 2 BSU BSU
Reconciliation
Incident Notified Required No A3 - Request and
by Fraud Information obtain missing
Provided ? information
Event 3 Yes
Transcash BSU
Deposit on ICL
Pathway Bank Ty f
P
Statement ‘Aq= Open RED eet From POCL
Further System Info. incident and
—_——_——— >I
From SSC record recon. Pro forma Fi PCHL
clock start time rom
Recognised II BSU
A8- Obtain [A = Request copy] by BSU as Yes Go to process
copy receipt/ receipt/tick-off Duplicate
. a bh. ‘pl A10 (see below
tick-off list and list and stop the RED bottom left)
provide to BSU recon. SLA clock I Incident ? No
BSU
Opportunity
to Correct Yes IA5 - Attempt corr-]
5 : , System lection of system
Until provided Records via records in conjun-
by POCL No ction with PCHL
Need to PCHL BSU
Retrieve Encashment ?
Receiptor IYes \ No Yes See
Tick-list ‘ Next
AQ - Re-start From t A6 - Investigate Page
the recon. Lisahally ? I w, and resolve Successful Correction ?
SLA clock “I? RED incident
BSU See above BSU
(top right) ALBsu_I Subsequent RED
A10- Cross-refer Recognised WMissmation eigen
duplicate and ens Report
aan . by BSU as
existing “master Duplicate
RED incidents RED From'SSC To
BSU Incident 2 DSS COPS (COLS)
mendent ¢ DSS BAB
B (0) POCL TP
Go to process A18 - See Next Page
COMMERCIAL IN CONFIDENCE
Page 68 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref: CS/PRD/0003
BA Reconciliation Process For ICL Pathway sersion: 20 59/08
Release 1c - PART 2 (Resolution)
POCL
From Previous Page From Previous Page
© To ICL Pathway Problem G)
Management - see Part 4
RED Incident
Report (annotated)I
Criteri
Met For Yes I All - Escalate to A21 - Close
Escalation Problem RED
to Problem No management incident
Incident ? BSU BSU
To ICL Pathway Fraud Criteria Yes
Management - see Part 5 Met For No [A207 Resolve
RED Incident Closing *\ I outstanding RED
Report (annotated) RED incident closure
Criteria Incident ? issues
Met For Yes are escalate RED Incident Al BSU
Esealation . management Closure Info.
to Fraud I No From Liability
Incident ? BSU Assignment (Part 3),
Problem Management
Resolution
Loop back to process A6
until resolution completed
(Part 4) and Fraud
Management (Part 5)
Complete ? ‘AIS - Check with] OK to Write Al9 - Trigger
. DSS COPS Cheque ? closure of HSH
Criteria Bus. Support OK No reconciliation
Met For to write cheque incident
Writing a BSU Al Bsu
ICL Pathway
Cheque ?, ie. Al4- Write
Underpayment < — and send to
Caused by customer
Manual Error .
in Fallback BSU
Operation To DSS COPS (COLS)
To Liability Assignment - see part 3 DSS BAB
RED Incident POCL TP
BSU Report (annotated)
Able to ‘Al6- Refer to Al7- Resolve Cleared
liability panel outstanding RED RED
incident clearanceI Incident
- issues. Report
Recon BSU No BSU y
ciliation . Clear RED
Liability I A!S- Assign Yes AI8 - Clear
Liability I pity where incident and
s applicable Criteria Met For stop SLA clock
BSU Clearing RED Incident? From process A10 BSU
COMMERCIAL IN CONFIDENCE
Page 69 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
8.2. Overview of Generic Process Model of ICL Pathway Reconciliation
8.2.1 Normal resolution and exceptions
The generic model caters for all types of reconciliation incident handled by ICL Pathway. The
bold arrows on the model show how resolution is normally progressed. The lighter arrows show
how exceptions are handled.
8.2.2 Resolution triggers (events 1, 2 and 3)
The normal trigger for reconciliation resolution is the receipt of a HSH raised reconciliation
incident within the BSU (event 1 on the process model). Part 1 Reconciliation Incident
Management describes the different types of reconciliation incidents raised by the HSH and how
they are routed to the BSU. Secondary triggers (event 2 and 3 on the process model) include
reconciliation incidents reported by ICL Pathway Fraud Management (paper-based
communication at Release 1c) and RED incidents raised by the BSU in response to a deposit
being shown on the ICL Pathway Transcash Account Bank Statement.
8.2.3. Pre-scan and related actions (process Al, A2 and A3)
HSH raised reconciliation incidents and incidents notified by ICL Pathway Fraud Management
are pre-scanned to check whether they are valid and to check whether the required information
has been provided. Invalid reconciliation incidents are routed back to the originator with an
explanation. Missing information is requested from the originator.
8.2.4. Opening of the RED incident and preliminary actions (process A4)
All valid reconciliation incidents communicated to the BSU are recorded on the RED. The
opening of an incident on RED includes the recording of the reconciliation SLA clock start time.
Any incidents recognised by the BSU as being duplicates are cross-referred to a “master” RED
incident (the incident already recorded on RED) and the duplicate RED incident progressed to
clearance. The opportunity to resolve the reconciliation incident by correcting the system
records via a dummy encashment at the PCHL is considered at this point.
8.2.5 Correction of system records via PCHL encashment (process A5)
In exceptional situations, e.g. a lost transaction observed by the post office, it may be possible to
correct the system records by performing an encashment at the PCHL - see section 8.5 for
further information. There is a limited “window of opportunity” for performing the corrective
action. If the corrective action is successful the incident is progressed to clearance. If
unsuccessful the incident is investigated and resolved in the normal way.
8.2.6 The Resolution Loop (process A6, A7, A8, A9, A10, All and A12))
The resolution processes operated by the BSU need to accommodate a wide range of
reconciliation incidents. Incidents may have been caused by system or manual errors and each
incident has a unique set of characteristics. Investigation is carried out to identify the intended
transaction, e.g. Authorised Payment = £x, the actual transaction, Encashment = £y, and the
difference £x-£y. Investigation also identifies other transaction information, ¢.g. customer
NINO, post office FAD code, etc. Resolution involves progressing, in conjunction with others,
correction of the ramifications of the system or manual errors within the ICL Pathway domain.
A RED incident report is circulated to DSS (COLS), DSS BAB, POCL TP and Service
Management at the beginning of the resolution activity. This describes the nature of the incident.
COMMERCIAL IN CONFIDENCE Page 70 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
Subsequent RED reports are circulated, at the discretion of the BSU, during resolution. Finally a
Cleared RED Incident Report is issued.
A number of questions are asked throughout resolution. The questions relate to the need to
retrieve receipt information, the need to filter duplicate incidents and the need to escalate to
Problem Management or Fraud Management. The SLA clock is stopped if there is a need to
recover copy receipts or tick-off lists (a list of receipts issued by a specific post office during a
cash account period) from Lisahally. The SLA clock is re-started when the required receipt
information is provided to the BSU.
The BSU updates the HSH reconciliation incident record with summary information during
resolution to enable the HSH to provide progress information if requested.
8.2.7 Actions after resolution is completed but before clearance (A13, A1l4, A15, A16,
and A17)
ICL Pathway has the authority to write and issue cheques to correct customer underpayments
caused by manual errors in fall-back operation. A check with DSS COLS (Business Support) is
included to avoid duplicate payment, e.g. the DSS may have already made a corrective payment
in response to direct customer communication with a DSS office.
In normal circumstances the BSU assigns liability in accordance with the agreed pre-defined
“Reconciliation Liability Matrix” - see Part 3 Liability Assignment (currently under
construction).
For RED incidents that have customer payment or settlement implications, clearance is
dependent on verbal agreement with DSS BAB and/or POCL TP. Any clearance issues are
resolved by the BSU before the incident is formally cleared on the RED.
8.2.8 Clearance of RED incidents (A18)
When the RED incident clearance criteria are met the BSU:
¢ stops the reconciliation SLA clock;
e changes the status of the incident on the RED to “cleared”;
e issues a Cleared RED Incident Report to DSS (COLS), DSS BAB, POCL TP and
Service Management.
The normal RED clearance criteria are:
e reconciliation incident details defined;
e resolution actioned by ICL Pathway (where ICL Pathway has authority to resolve, e.g.
fall-back underpayment payment errors) or progressed to the agreed “DSS hand-over
point” (where ICL Pathway does not have authority to resolve, e.g. automated payment
errors corrected by the DSS using information provided on the Cleared RED Incident
Report);
liability assigned in accordance with the pre-defined Case Law and Resolution Liability
Matrix;
¢ verbal agreement to clear the incident obtained from DSS BAB or POCL TP
(Development Assurance) if the reconciliation incident has customer payment or
settlement implications.
In exceptional situations RED incidents may al: leared if
COMMERCIAL IN CONFIDENCE Page 71 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
e the reconciliation incident has been accepted by ICL Fraud Management and is on hold
pending a fraud investigation;
e ICL Pathway Problem Management (in conjunction with DSS Problem Management)
have accepted that the reconciliation incident is part of a larger problem which is being
resolved by Service Management, ICL Pathway, DSS or POCL problem management
authorities;
¢ the reconciliation incident is not covered by the pre-defined Case Law and Reconciliation
Liability Matrix and has been referred to the Tripartite Liability Panel. (Refer to Part 3
Liability Assignment)
8.2.9 Triggering closure of HSH reconciliation incidents (A19)
Following clearance of the RED incident the BSU triggers closure of the HSH reconciliation
incident.
8.2.10 Closure of RED incidents (A20 and A21)
When the RED incident closure criteria are met the BSU changes the status of the RED incident
to “closed”.
Some RED incidents pass directly from clearance to closure. These include:
¢ reconciliation incidents that are covered by the pre-defined Reconciliation Liability
Matrix and have been handed over to the DSS for resolution, e.g. correction of
automated payment errors, correction of fall-back over-payment errors; . (Refer to Part 3
Liability Assignment)
e reconciliation incidents that have been resolved by ICL Pathway, require no further
action and have no customer payment, settlement or liability implications, e.g. correction
of system records via PCHL encashment
Other RED incidents remain in the cleared state until confirmation of resolution has been
received. They include:
e reconciliation incidents that have been resolved by ICL Pathway writing and issuing a
cheque - these are closed when the ICL Pathway Bank Statement shows that the cheque
has been cashed;
¢ reconciliation incidents that have been escalated to Fraud Management, Problem
Management or the Tripartite Liability Panel - these remain in the cleared state until
notification of complete resolution is provided to the BSU and any closure issues are
resolved.
8.3 Supporting Services Provided to the BSU, Roles, Responsibilities and
Dependencies
The following describes the supporting services provided to the BSU.
8.3.1 ICL Pathway Horizon System Helpdesk (HSH)
The reconciliation support service provided by the HSH includes:
e raising HSH reconciliation incidents in response to valid telephone calls from the DSS,
POCL, post offices, and ICL Pathway organisations - see Part 1 Reconciliation Incident
COMMERCIAL IN CONFIDENCE Page 72 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date = 14/09/96
POCL
Management;
© capturing an agreed set of information within the HSH reconciliation incident record
during the initial telephone call - failure to capture the required information will delay
resolution;
¢ including the word “RECON” at the beginning of the HSH reconciliation incident record
text;
e routing HSH reconciliation incidents to the SSC for onward routing to the BSU - system
constraints currently prevent reconciliation incidents being routed directly to the BSU.
8.3.2 ICL Pathway System Support Centre (SSC)
The reconciliation support service provided by the SSC includes:
¢ routing of HSH raised reconciliation incidents to the BSU;
© providing system information to support the opening of a RED incident and subsequent
investigation and resolution;
¢ routing of cleared reconciliation incidents back to the HSH for closure.
8.3.3. ICL Pathway Problem Management
(Refer to Part 4 Interactions Between Service and Problem Management)
The reconciliation support service provided by ICL Pathway Problem Management includes:
e notifying the BSU with relevant information (detail tba) relating to pure system incidents
that have unexpectedly caused “transaction record level” reconciliation implications;
¢ notifying the BSU with relevant information (details tba) relating to pure system incidents
that have unexpectedly caused “file level” reconciliation implications;
¢ receiving RED incident reports from the BSU (annotated to describe a wider issue or a
perceived adverse trend);
¢ receiving RED incident reports from the BSU in situations where a customer has
reported “No Payment Available”; or the customer has refused to accept a payment,
e resolving “No Payment Available” incidents, or situations were the customer has refused
to accept a payment, in conjunction with ICL Pathway technical and operations
authorities;
© providing information to enable closure of RED incidents when RED incident closure has
been put on hold pending problem resolution.
The raising of HSH reconciliation incidents in response to the first two bullets is at the discretion
of the BSU. File level reconciliation implications require the ongoing involvement of Problem
Management and require the SSC to provide additional information that identifies the individual
records contained with the affected file.
8.3.4 ICL Pathway Fraud Management
(Refer to Part 5 Interactions with Fraud Management)
The reconciliation support service provided by ICL Pathway Fraud Management includes:
COMMERCIAL IN CONFIDENCE Page 73 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
¢ notifying the BSU of reconciliation incidents identified during fraud investigation;
¢ receiving RED incident reports from the BSU (annotated to describe an apparent fraud
issue);
© providing information to enable closure of RED incidents when RED incident closure has
been put on hold pending fraud investigation.
8.3.5 Liability Panel
(Refer to Part 3 Liability Assignment)
8.3.6 DSS BAB
The reconciliation support service provided by DSS BAB includes:
¢ receiving RED incident reports;
¢ where appropriate agreeing clearance of DSS related RED incidents.
8.3.7 POCL TP
The reconciliation support service provided by POCL TP includes:
¢ receiving RED incident reports;
¢ where appropriate agreeing clearance of POCL related RED incidents.
8.3.8 DSS COLS
The reconciliation support service provided by DSS (COLS) includes:
e receiving RED incident reports;
e fall-back underpayment errors,
providing the BSU with the go ahead to write and issue a cheque or an instruction to not
write a cheque - COLS Business Support will know whether the DSS has already made
an “emergency” payment to correct an underpayment payment situation and will
therefore be able to prevent duplicate corrections of underpayments;
e for fall-back overpayment errors,
receiving the RED incident clearance report and communicating the fall-back
overpayment error to the relevant DSS authorities - two situations exist:
— the ICL Pathway investigation confirms that an overpayment was made during fall-back
operation;
— acustomer makes a deposit to the ICL Pathway Transcash account;
e for automated underpayment or overpayment errors,
receiving the RED incident clearance report and communicating the underpayment or
overpayment error to relevant DSS authorities.
8.3.9 POCL Service Management
The reconciliation support service provided by Service Management includes:
¢ receiving requests from the BSU for:
— post office receipt information during the current cash account period.
COMMERCIAL IN CONFIDENCE Page 74 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date = 14/09/96
POCL
— copy receipts or tick-off lists from Lisahally after the end of the current cash account
period;
© providing receipt and tick-off list information to the BSU to enable resolution of
reconciliation incidents.
COMMERCIAL IN CONFIDENCE Page 75 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref: CS/PRD/0003
BA Reconciliation Process For ICL Pathway Version: 2.0
Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
8.4 Link Between RED Incidents and Resolution Actions
The following table provides a link between the reconciliation incident types shown in Part I
Reconciliation Incident Management (Section 8.7) and the actions required to resolve the RED
incident. The resolution actions are defined in section 8.6.
From RED Incident Type Resolution action
(see section 8.6)
DSSITSA I e DSS office reported customer payment I I, 5a, Sb, 6a, 6b, 7,
error 8.
© DSS identified PAS exception 1,2, 4,9, 10, 11.
© BAB identified reconciliation incident I 1. 2.
POCL TP POCL observed reconciliation incident 1, 2,3.
Payment e Fall-back payment query 1, 13, 14.
Card Help
Line
© Operator error during —_ remote I 1, 3, 16.
encashment
Post Office I Operator error during —_ normal I 1, 3, 12.
encashment
¢ Receipts missing from BES report I 1 3
(possible lost transaction) >
ICL ¢ 10 Day — Report — Unmatched I 1,2,4,9,10,11
Pathway Encashment
Customer
Service
COMMERCIAL IN CONFIDENCE Page 76 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
8.5 Attempt Correction of System Records in Conjunction With PCHL (expansion
of process A5 - see section 8.1)
Start Process AS
v
AS.1 - Instruct
PCHL to perform
encashment
BSU
Y
A5.2 - Attempt
encashment
PCHL
v
AS.3 - Inform
BSU of success
or failure
PCHI
eo cashment
Successful ?
Yes
A5.4 - Comfirm [A3.5 - Inform PO
encashment lof encashment
details & advise to
carried out
lannotate receipt
Receipt Sent
to Lisahally ?
[A5.6 - Annotate [A5.7 - Record
loriginal receipt IPCHL encashment
jwith PCHL encashI etails on anew
Lment details anual receipt
PCHL
I<
Process AS
complete
COMMERCIAL IN CONFIDENCE Page 77 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway Version: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
8.6 Resolution Actions (expansion of process A6 onwards)
The following defines the resolution actions that follow the investigation carried out by the ICL
Pathway Business Support Unit during process A6 - see section 8.1. All identified resolution
activities have been included for completeness. However, some may never occur or only occur
in very exceptional circumstances.
Ref I BSU investigation Subsequent resolution I Subsequent actions (other
result actions (ICL Pathway BSU) I organisations)
1 ICL Pathway systems Ie Update RED and HSH
and processes shown to incident records.
be OK - no fault found, * Distribute clearance RED
incident report.
e Clear and close RED
incident.
2 Duplicate encashment Ie Update RED and HSHIe DSS (COLS) advise
identified within ICL incident records. ChB CSU that
Pathway systems, e.g. I I Assign liability. overpayment exists
one AP more than one © POCL/DSS djust
E e Distribute clearance RED acjus
no settlement.
incident report.
* Clear and close RED
incident.
3 “Hidden” duplicate I e Update RED and HSHIe* DSS (COLS) advise
encashment identified, incident records. ChB CSU that
eg. one AP, first Bae overpayment exists.
encashment record lost, I * Assign liability. * POCL/DSS adjust
second encashment I e Distribute clearance RED J
. : . settlement
recorded, i.e. customer incident report.
Paid twice. e Clear and close RED
Note: This _ situation incident.
arises when it is too late
to recover, ic. the
opportunity to use
process AS (see section
in 8.5) has past.
4 Failed stop or expiry] Update RED and HSH Ie POCL/DSS adjust
identified in ICL incident records. settlement.
Pathway systems. © Assign liability
© Distribute clearance RED
incident report.
e Clear and close RED
COMMERCIAL IN CONFIDENCE
Page 78 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway Version: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
© incident.
Sa Confirmed that the “no Ie Update RED and HSH Ie ICL Pathway Problem
payment available at
post office” incident
raised via ITSA was
caused by an ICL
Pathway system error,
e.g. AP in PAS but not
incident records.
e Contact HSH and request
HSH recon. incident be
escalated to ICL Pathway
Problem Management.
Management ensure
that the ICL Pathway
system records are left
in a suitable state.
in BES. Also ITSAIe Clear RED __ incident
raised HSH _ recon. report.
incident record shows . .
that the DSS hasI* Await confirmation from
Iready issued a sto} ICL Pathway Problem
already Pp
and taken action to pay Management that
the customer. problem has been
resolved.
© Close RED incident.
5b As above but ITSAIe Contact DSS COLS I As Sa above.
raised HSH recon. Business Support and
incident does not either confirm that the
confirm that the DSS DSS have already issued
has issued a stop and a stop and corrected the
taken action to pay the payment or request that
customer. they do so.
« Update RED incident and
await confirmation from
COLS Business Support.
Then proceed as
described in Sa above.
6a Confirmed that the I As Sa. above. As Sa above.
“customer rejected
payment at the post
office” incident raised
via ITSA was caused by
an ICL Pathway system
error, e.g. corrupted AP
in BES. Also ITSA
raised HSH recon.
incident record shows
that the DSS has
already issued a stop
and taken action to pay
the customer
6b As above but ITSA I As Sb above. As Sa above.
raised HSH recon.
COMMERCIAL IN CONFIDENCE
Page 79 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway Version: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
incident does not
confirm that the DSS
has issued a stop and
taken action to pay the
customer.
7 Confirmed that the Ie Update RED and HSH]e DSS (COLS)
“customer queried incident records. communicate
underpayment” incident eae information on
raised via ITSA was I ° Assign liability. clearance RED
caused by an ICL] e Distribute clearance RED incident report to ChB
Pathway system error, incident report. CSU.
cg. corrupted AP e Clear and close REDI«* ChB/DO correct
encashed (outward leg incident. underpayment using an
system error). alternative method of
payment.
Note: ChB / DO may
have corrected _ the
underpayment before the
clearance RED _ incident
report is distributed.
8 Confirmed that the I As 7 above. e DSS (COLS)
“customer queried communicate
overpayment” incident information on
raised via ITSA was clearance RED
caused by an ICL incident report to ChB
Pathway system error, CSU. (COLS) advise
eg. corrupted AP ChB of the
encashed (outward leg overpayment.
system error).
9 Confirmed that the DSS I As 7 above. As 7 above.
PAS exception incident
raised by COLS via
ITSA and/or __ the
unmatched encashment
incident raised by ICL
Pathway BSU_ was
caused by an ICL
Pathway outward leg
underpayment — system
error
10 As above but I As 8 above. As 8 above.
overpayment error.
11 Confirmed that the DSS I e Update RED and HSH
PAS exception incident incident records.
raised by COLS via
COMMERCIAL IN CONFIDENCE Page 80 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway Version: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
ITSA and/or __ the Confirm with the SSC
unmatched encashment that the return leg
incident raised by ICL encashment information
Pathway BSU_ was will be corrected.
caused by an ICL ‘Awai i ion fi
Pathway return leg wait confirmation from
system error. the SSC that the return
leg encashment
information has been
corrected.
Distribute clearance RED
incident report.
Clear and close RED
incident.
12 Confirmed that the post Update RED and HSHIe COLS Business
office committed an incident records. Support advise ChB to
encashment but did not Contact COLS Business correct underpayment.
pay the customer, e.g. Si rt and t that
unintentional thon i ane request thal
commitment. hey initiate a payment
via an alternative method
Note: the opposite to of payment.
the above, i.e. failing to . .
commit is corrected by Await confirmation that
process AS (see section the DSS will pay the
8.5) if still within the} Customer.
“window of I e Assign liability.
opportunity” or 3 above an
if outside. Distribute clearance RED
incident report.
Clear and close RED
incident.
13 Confirmed that an Update RED and HSH
underpayment was incident records.
made in fallback. Confirm with COLS
Business Support that it
is OK to write a cheque.
If yes write and issue a
cheque. If no because
the DSS has already
corrected the
underpayment via an
alternative method of
payment, take no further
action.
e Assign liability.
COMMERCIAL IN CONFIDENCE
Page 81 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
© Distribute clearance RED
incident report.
e Clear and close RED
incident.
14 Confirmed that anIe Update RED and HSH] (COLS) advise ChB of
overpayment was made incident records. overpayment.
in fallback. ea .
in fallbac e Assign liability. ¢ POCL/DSS adjust
settlement.
© Distribute clearance RED
incident report.
e Clear and close RED
incident.
15 I Confirmed that Ie Update RED and HSHIe* POCL amend _ their
incorrect information incident records. system records.
was passed across the ss
ABED link. e Prepare and distribute a
special report to POCL
TP detailing errors and
correct values.
© Distribute clearance RED
incident report.
e Clear and close RED
incident.
16 Confirmed that the I Treat as fall-back
PCHL committed an I underpayment for the total
encashment but I amount, as 13 above.
customer was not paid.
Note: the opposite to
the above, i.e. failing to
commit is corrected by
process AS (see section
8.5) if still within the
“window of
opportunity” or 3 above
if outside.
17 Other cases Treat as special case, I As requested by BSU.
determine best way to
resolve and add to known
resolution list.
COMMERCIAL IN CONFIDENCE Page 82 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
9 Post Office Reconciliation Resolution
The post office play the following roles in reconciliation resolution:
e Resolution of fall-back errors during the current cash account period, subject to
restrictions - See Para R11 in section 6.5.1.
© Contributing to the correction of lost encashment transaction data - See section 8.5.
¢ Receiving the voluntary return of money via transcash - see below.
9.1 Offer By Customer To Return Money When Payment Errors Have
Been Made In Fall-back (Transcash)
ICL Pathway will operate a Transcash account to receive, across post office counters,
any voluntary return outside the cash account period of over-payments made in fall-back
(but not in normal working). Before the end of the cash account period the post offices
maybe be able to make corrections without the need to invoke formal reconciliation - see
principle R11 in section 6.5.1
Very few, if any, of these repayments are expected. The facility has been established to
avoid any embarrassment if such a repayment is proffered.
The post office telephones the Payment Card Help Line (PCHL) to check that the
repayment is for a fall-back encashment. Most of these will be for a fall-back encashment
performed via the PCHL (“99” in positions 7 and 8 of the encashment transaction serial
number). In these cases the PCHL will be able to confirm the correct amount from its
records and enable the post office to verify the repayment amount by deduction from the
amount shown on the customer’s payment receipt.
For fall-back encashments where the amount was transcribed from the screen because the
printer was not working, the PCHL will not have the data after two days and:
. if the original encashment was in the previous cash account period it advises the
post office to run a BES transaction listing and check the amount there;
. otherwise (which should be very rare) the PCHL refers the inquiry to Pathway
customer services where the correct amount is looked-up and telephoned back to
the post office.
Accepting the repayment at the post office counter is based on the standard Transcash
product, with no special stationery provided in view of the extremely low expected
incidence. However, use of the standard Transcash form means that the amount receipted
shows a 90p fee deducted, and procedures advise that the clerk should assure the
customer that this will be adjusted centrally to credit the full amount.
NB: the above reflects normal practice for general-stationery Transcash.
The procedures held in the post office give the relevant Pathway Transcash account
number and instructions for information (including the NINO and encashment transaction
reference number) to be noted on the back of the in-payment slip. This slip will be
returned by Girobank to ICL Pathway Customer Services and form the basis of the
incident record on the RED.
COMMERCIAL IN CONFIDENCE Page 83 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
Further action depends on how far any detection of overpayment has gone. POCL
Transaction Processing in Chesterfield will be advised so that it can account for any
discrepancy between ABED data and the relevant post office cash account entry, which
may or may not already have been detected. DSS BAB will be notified via a RED
incident report.
COMMERCIAL IN CONFIDENCE Page 84 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway Version: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
10 Recovery of Payment Receipts From Lisahally
Ref. _] Reconciliation Resolution Principle ‘Action By
R23 Where information from payment receipts is needed this will be obtained
from a central point, initially in POCL Service Management:
© copy payment receipts will be obtained from Paid Order Unit (POU)
Lisahally and distributed by POCL Service Management to relevant
parties;
¢ where necessary (e.g. urgent need and no danger of alerting a suspect
to a fraud inquiry) the central point may request payment receipt
detail from post offices over the telephone (before the end of the cash
account period);
© POU Lisahally may be asked to check (“tick-off”) stored payment
receipts for a post office for a cash account period against a system
transaction list:
* this would be needed if the post office cash account BES entry did not
match the ABED figures with no apparent explanation:
this long stop check should be rare in Release lc and should not be
necessary (because of EPOSS and payment receipt recovery facilities) in
Release 2;
POCL _ Service
Management
POCL _ Service
Management
COMMERCIAL IN CONFIDENCE
Page 85 of 95
FUJ00058360
FUJ00058360
Report
Settlement
idjust
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathwa' ersion: 2.
BA Y Date 14/09/98
Release 1c - PART 2 (Resolution)
POCL
10.1 Recovery of Payment Receipts from Lisahally
POCL (TP team) BAB COPS Pathway Business Support
POCL accounting error BA accounting error BA accounting error Pathway need a copy
investigation need copy _ investigation need copy _ investigation need copy of receipt details
of receipt details of receipt details of receipt details \
I + I Complete
Are receipt requistion form
details known ? and fax to POCL
Yes Central Receipt Pt]
© ] POC, BAB,
No COPS & P/W BS
Phone POCL CRF
Log details and to notify of fax
access urgency Fin transit
POCL - Central POCL, BAB,
Receipt Point COPS & P/W BS
Call PO outlet
and confirm
receipts on-hand
POCL - Central
Receipt Point
Is it worthwhile
phoning the
PO outlet ?
Have receipts
been
despatched ?
No
Log incident & despatch
requsition to Paid Order
Unit at Lisahally via Fax
or Email
POCL - CRP POCL - CRP
and PO
Request check
of receipts held
Register request, calculate
timescales (receipt on handI ”
date required by requestor) details to POCL
complete marker slip CRP
Lisahally: Order PO Staff
retrieval duty
® ®@)
COMMERCIAL IN CONFIDENCE Page 86 of 95
Relay receipt
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
M
Copy receipt Record required receipt
Lisahally: Order POCL - CRP and PO
retrieval duty
Log receipt details & copy.
Replace receipt & ; Fax info. to requestor and
despatch copy to POCL other expected users with
CRP. record of original requestor
Lisahally: Order POCL - CRP
retrieval duty
-Keep further copy for
unexpected requests.
POCL - CRP
equestor
receives
receipt
details
DN:(i) Payment receipts may be removed from either POU Lisahally or (in exchange for a
form including all pertinent details) a post office by BA fraud staff. It should be
agreed with POU Lisahally that details remain available when payment receipts are
removed. The information required will then be available to support the above
process.
(ii) BA COBAP has not yet formally agreed this process with POU Lisahally.
COMMERCIAL IN CONFIDENCE Page 87 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
Appendix A
Disputed Encashment - Repudiation.
There may be instances when a customer disputes that they have received a payment that the
system shows as having been encashed. The following process map covers the actions to be
taken before initiation of fraud action, including eliminating system error and customer mis-
understanding.
COMMERCIAL IN CONFIDENCE Page 88 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref. CS/PRD/0003
BA Reconciliation Process For ICL Pathway Neision: 20 0/98
Release 1c - PART 2 (Resolution) ate
POCL
DISPUTED ENCASHMENT/REPUDIATION
CUSTOMER at DO
PaymentReceived
by CPCS? Payment Due?
Customer Obtain Details Counter Clerk Rect. :
Disputes Encashment Odie [BY teterhones CSU [BE] CSU Checks CPs30 Te
Yes
Goto Process 12
ccalled, Expired
‘and Suppressed
T
1
1
1
1
1
8 Advise Customer 9
Acces FBS and Check II or Correct Payment
Def Entitlement Payability
Due Date
Deals of p
Card swiped at PO [>
Customer ha NPO
DN CSU will probably
) call customer back
Overnight Batch?
ny Advise Customer
Has Pyt Been Sem/\ Yes Reissue Pyt of Situation
toCPCS? and Raise Incident
; te su
su
‘ Advise 7
@
Advise
Customer
Customer
COMMERCIAL IN CONFIDENCE Page 89 of 95 a]
ICL Pathway
POCL
Benefit Payment End to End
BA Reconciliation Process For ICL Pathway
Release 1c - PART 2 (Resolution)
Ref: CS/PRD/0003
Version: 2.0
Date 14/09/98
FUJ00058360
FUJ00058360
Payment Cashed?
Did Customer Go To
(Owy PO?
>
Y
Restricted PO?
Yes
‘Check Eneashment
Details On
CP530S11
18
Advise Customer to
Got RPO
=
Other Payee a
Cashed Payment? N
1B
Advise Customer
To Contact OP
[epee
Payment Cashed?
T
rele COPS Adviceline
PI to Request Pymt
Details from PAS
COPS Advicelis
Tele PCHL to Request
-
Pymt Details on PAS
[ss
[et Yes
Advise Customer Of
Pymt Details and. -———— > Give CAPS 52
‘onfirm No Pymt Rect
Eee
Other Payee
Cashed Payment?
Customer Confirms
No Payment Received?
Bu
Yes To Customer
No bo
Refer to Customer
Process Maps at Pa
Payment
aras 7 to 7.4
2
Advise Customer
To Contact OP
[epee]
Advise Customer
‘Of Due Date
Of Next Pymt
Customer ~
ar
Te
Refer CAPS 52To
Fraud Section
[%
Completes/Signs
CAPS 52
[
OP Confirms
Encashment?
Give CAPS 52
A $e] completes/signs
To Customer
Customer 13
Fax CAPS 52
to CSU
—
jo to Process 26
CAPS 52
Eee
fe]
I
COMMERCIAL IN CONFIDENCE
Page 90 of 95
ICL Pathway
BA
POCL
Benefit Payment End to End Ref. CS/PRD/0003
Reconciliation Process For ICL Pathway Neision: 20 0/98
Release 1c - PART 2 (Resolution) ate
FUJ00058360
FUJ00058360
— HX
6
PI 80 Raise ncident
with COLS BS
csu
2
COLS BS Determine
if Encash. Committed
in Error
COLS
Committed in Evvon?
Refer to Fraud Process Map
To be included in Part II Pathway Rel. 2 and Part V Interactions with Fraud Mgt.
CSU Consider Refer to Local
Ye Replacement Action Payment Procedures
Customer Require Gu
Urgent Payment?
Await Outcome
Of Fraud
Investigations
DN From Pathway Rel2 (Parts If and V) Fraud Processes will include
the possible interview of the Customer in the DO by a FO and invalidating the card
as appropriate
# = 7
[cos [cs Lv
COMMERCIAL IN CONFIDENCE Page 91 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End per SB/PRDI0008
Reconciliation Process For ICL Pathway ersion: 2.
BA Release 1c - PART 2 (Resolution) Date 14/09/98
POCL
Appendix B
Inactivated Cards
In cases where the card has not been activated cither because of human error or loss of data, the
customer will be told at the PO that no payment is available and offered a nil receipt.
The following process models detail, firstly how the PO activate the card and secondly how it is
proposed to resolve the problem of the customer not being able to collect payment because the
card is inactivated.
The post office have enhanced current procedures (including redesigning the screens to make the
procedures easier to follow) to help, eradicate/reduce instances of inactivated cards. However
the above instances could still occur when “activation data is lost”.
COMMERCIAL IN CONFIDENCE Page 92 of 95
FUJ00058360
FUJ00058360
ICL Pathway Benefit Payment End to End Ref. CS/PRD/0003
BA Reconciliation Process For ICL Pathway Neision: 20 0/98
oc Release 1c - PART 2 (Resolution) ate
POCL
APPENDIX B
it occurs and NOT
INACTIVATION Note: For this particular incident we are interested in how inactivation arises and how to resolve the probl
and issue process models,
PROCESS in the exceptions such as faulty or missing cards from batch which are dealt with in generic card producti
PCDF = Pathway Card Distribution Facility. It is the counter element of CMS recording/reconciling distribution of cards. CMS holds PO and no’s of cards issued.
POCC =PO Counter Clerk.
T z > 7
Seanfnput Reconcile No's OF Counter Clerk File Cards a siwait Collection commer
paced BMY Sitonach BR] Sherr Braco pan PB Arcot pe coxme Pees
Tocs Individual Card in Secure Place In PO
Par = E= ree y oe
Seana Code
‘On PUN
Poor I pace
y=
Collet New Card
From Secure Location
Y Poot
Verity Card Details
Y=
Kiet vedinaond [EAP sogerincay [MEA] commen FP tec
= F= E F=
COMMERCIAL IN CONFIDENCE Page 93 of 95
ICL Pathway
Benefit Payment End to End
BA Reconciliation Process For ICL Pathway
Release 1c - PART 2 (Resolution)
Ref: CS/PRD/0003
Version: 2.0
Date 14/09/98
FUJ00058360
FUJ00058360
POCL
APPENDIX B
INACTIVATION
ROCESS - RESOLUTION
Refer to Local Pymt Procedures
fa PCHL ' Urgent Pymt
II toestablish whether! Card Customer Has Latest Requested?
it activated? PUN? ;
oy : , Yes u To
SEEPROCESS MAPS I; Card Activated yy ee Consider Making Await Receipt OF
FOR DUE PAYMENT II i Local Payment New PUN.
ae \ Refer to process 5 of
(NIL RECEIPT) fall i Yes PCHI No I Dss I Dss previous model
I I! Payment to '
aoa ' Correct PO I
IDNPCH ned io! I ' 0
[ establish associated I) I 1 Advise Cust Advise Cust To 7
1 PUN details t Payment ' To Return to PO Await Receipt of PUNICard Retumed >
I__frompss.__I PF Marooned ' New PUN. ToCut
L 2 Dss
A Occ
Refer to
Customer Pymt Card/PUN 7
Models to POCC Pymt Made To Cust
y Cust j POCG
3 ri 5 6
Scan PUN He I Verify Customer Hm] Swipe Card i] Swipe Card Again
° 1D To Activate To Access BES
[rece I [roce [poce [roce
COMMERCIAL IN CONFIDENCE
Page 94 of 95