FUJ00119561
FUJ00119561
DSS/POCL Pathway
Functional
Specification sine I
P ‘0
BRINGING
TECHNOLOGY
‘TO POST OFFICES
AND BENEFIT
PAYMENTS:
Commercial-in-Confidence
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
i DSS/POCL Functional Specification Version: 3.0
ay Date: 22/5/96
Document Title:
Document Type:
Abstract:
Distribution:
C3 Document Status:
Document Predecessor:
Associated Documents:
Author/Editor:
Approval Authority:
— Signatures/Dates:
NN
Comments To:
Comments By:
DSS/POCL Functional Specification
Functional specification
This document provides the functional specification in
accordance with Schedule B7 of the Authorities’
agreement. This version is for DSS, POCL.and
Pathway review.
DSS
POCL
Pathway I
Pathway Library
Issued
Version 2
See section 0.2
John C C Dicks
For Pathway:
J H Bennett
For POCE
tba
For DSS
tba
Author, copy POCL and DSS contact points
14/6/96
&
Printed: 22/05/96
C:\FINALPRN\PFITOC.DOC
COMMERCIAL-IN-CONFIDENCE
Page 1
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
0. CONTENT
0.1 DOCUMENT HISTORY
_ {Version I Date Reason
0.1 29/4/96 _I Early visibility of scope, purposes and objectives
1 10/5/96 _I For Pathway review
2 17/5/96 ___I For Pathway approval
3 22/5/96 For DSS, POCL ard Pathway review
4 21/6/96 __I Revision following reviews
5 29/6/96 _I For DSS, POCL and Pathway approval
0.2 ASSOCIATED DOCUMENTS
Version Date Title Source
6 06/03/95 __I Statement of Service Requirements I DSS/POCL
1.5 27/02/96 I POCL Interface Requirements for I POCL
BA/POCL System
5 22/1/96 I CAPS to-PAS/CMS Interface DSss
Definitions
2 23/2/96 _I BPS MIS Requirements Catalogue _I DSS/POCL.
1 9/2/96 BA/POCL Service Interface DSS/POCL
Definition
1 19/3/96 _ I Memorandum of Understanding POCL _
1 16/4/96 Invitation to Retender, schedule DSS/POCL
B3 amendments to ITT baseline.
7/5/96 Contract Schedules DSS/POCL
7/5/96 Requirements Catalogue DSS/POCL
tba POCL APS Generic Rules POCL
tba Token Technology Specifications _I POCL
tba Automated Payments Client POCL
Specifications
tba DSS Client Interface Specification - I. DSS
OBCS
tba OBCS Processing Rules DSS
Printed: 22/05/96
C:\FINALPRN\PFITOC.DOC
COMMERCIAL-IN-CONFIDENCE
Page 2
FUJ00119561
FUJO0119561
Pathway Ref: PFS/PA/O01 I
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
0.3 ABBREVIATIONS
A&L Alliance & Leicester Building Society
ACC Area Computer Centre
ACD Automated Call Distribution
API Application Programming Interface
APS Automated Payment Service
ATM Automated Teller Machine
BA Benefits Agency
BES Benefit Encashment Service
BPS Benefit Payment Service
BT British Telecom 7
CAN Card Activation Number
CAPS Customer Accounting and Payments Strategy
CAS CAPS Access Service
CBOS Common Basis of Settlement
CESG Communications-Electronic Security Group
CHAP Challenge Handshake Authentication Protocol
CLI Calling Line Indication
CMS Card Management System
COBC Cashing Other Banks Cheques
CRC Cyclic Redundancy Check
CRU Cash Remittance Unit
DNS Department of National Savings
DSS ~Department of Social Security
DVLA Driver and Vehicle Licensing Authority
EPOSS Electronic Point Of Sale Service
ESNCS Electronic Stop Notice Control System
FAD Financial Accounts Division (of the Post Office)
Forde Machine currently used to calculate Western Union
foreign exchange rates
FS Functional Specification
FTF File Transfer Facility
GDN Government Data Network
GSM Groupe Systeme Mobile
HSO High Security Option
HTML Hypertext Mark-up Language
ID Identity
IM Inventory Management
IP Internet Protocol
ISDN Integrated Services Digital Network
IT Information Technology
ITS IMS to TMS System
ITS Agent The software module which inserts/extracts IMS-related
data to/from TMS
Printed: 22/05/96
C:\FINALPRN\PFITOC.DOC
COMMERCIAL-IN-CONFIDENCE
Page 3
Pathway
Ref:
DSS/POCL Functional Specification ~~~ Version:
Date:
FUJ00119561
FUJ00119561
PFS/PA/O01
3.0
22/5/96
ITS Host
KMS
LAN
LNFS
MAC
MCR
MoP
MOT
MVL
NINO
NTVLRO
OBCS
ONCH
OPS
OSPF
PACE
PAGL
PAN
PAS
PFI
PIRPBS
PIVOT
PO
_ POCL
PPP
PSI
PSTN
PSTN
PUN
RIP
RTF
SADD
SCR
SHA
SID
SIS
SMDS
SQL
SSA
TIP
TMS
TTS
TTS Agent
The platform on which the ITS runs
Key Management System
Local Area Network
Local NINO File System
Medium Access (Layer)
Magnetic Card Reader
Method of Payment
Ministry Of Transport
Motor Vehicle Licence
National Insurance Number
National Television Licence Records Office
Order Book Control Service
Overnight Cash Holdings
Office Platform Service
Open Shortest Path First
Police & Criminal Evidence
Programme Accounting General Ledger
Primary Account Number
Payment Authorisation Service
Private Finance Initiative
POCL Interface Requirements for BA/POCL System
document. Currently version 1.5, 27 February 1996
Postmaster’s Information on Volumes Of Transactions
Post Office
Post Office Counters Ltd
Point-point Protocol
POCL Service Infrastructure
Public Switched Telephone Network
Public Switched Telephone Network
Pick Up Notice
Routing Information Protocol
Rich Text Format
Service Architecture Design Document
Smart Card Reader (/Encoder)
Secure Hashing Algorithm/Digital Signature Algorithm
BA/POCL Service Interface Definition
Strategic Infrastructure Service
Switched Multi-megabit Data Services
Structured Query Language
Social Security Agency (NI)
Transaction Information Processing
Transaction Management Service
TIP to TMS System
The software module which inserts/extracts TIP-related
data to/from TMS
Printed: 22/05/96
C:\FINALPRN\PFITOC.DOC
COMMERCIAL-IN-CONFIDENCE
Page 4
FUJ00119561
_ FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
TTS Export The Oracle7 application which takes data from TIP and
converts it to the database format required by the TTS
Agent
TTS Host The platform on which the TTS runs
TTS Import The Oracle7 application which takes information from
the TTS agent and converts it to the format required by
TIP
UDP User Datagram Protocol.
VME Virtual Machine Environment
WAN Wide Area Network
WPA War Pensions Agency
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENC
C:\FINALPRN\PFITOC.DOC Page 5
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
0.4 TABLE OF CONTENTS
0. CONTENT.
0.1 DOCUMENT HISTORY...
0.2 ASSOCIATED DOCUMENTS.
0.3 ABBREVIATIONS .....c.ssesseseseeenee
0.4 TABLE OF CONTENTS
1. ABOUT THIS DOCUMENT ...........s0eseeeeee seentessesentosees
1.2 STRUCTURE AND SCOPE. coe eaeseaeeneeeenees
1.2.1 CONTRACTUAL BASIS OF STRUCTURE
1.2.2 PFI SERVICE LEVEL COMPONENTS
2. PFl SERVICE ARCHITECTURE.
2.1 PFI SERVICE INFORMATION FLOWS
2.2 PATHWAY SERVICE COMPONENT RELATIONSHIPS
2.3 BPS END-TO-END SERVICE DEFINITION
2.3.1 PFI RELATIONSHIPS...
2.3.2 A WALK-THROUGH OF BPS.
2.4 PFI SECURITY ARCHITECTURE.
2.4.1 SECURITY STRATEGY...
2.4.2 SECURITY DOCUMENTATION
2.5 BUSINESS CONTINUITY.
2.5.1 CONTINGENCY...
2.6 FRAUD RISK MANAGEMENT
2.6.1 INTRODUCTION sseseben
2.6.2 FRAUD RISK MANAGEMENT SERVICE ELEMENTS
2.6.3 DATA PROTECTION ACT, 1984
3. DSS SERVICE ARCHITECTURE
3.1 DSS STEADY STATE SERVICE ....
3.1.1 CARD MANAGEMENT SERVICE..
3.1.2 CARD MANAGEMENT SERVICE HELP DESK
3.1.3 TEMPORARY TOKEN PRODUCTION AND ISSUE ....
3.1.4 PAYMENT AUTHORISATION SERVICE
3.1.5 PAYMENT AUTHORISATION SERVICE (PAS) HELP DESK.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFITOC.DOC Page 6
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
3.1.8 CAPS ACCESS SYSTEM (CAS ).........
3.1.9 PAS RECONCILIATION REQUIREMENTS.
3.1.10 CMS RECONCILIATION ...
3.1.11 DSS CONTINGENCY SERVICES...
3.1.12 RELEVANT OPTIONAL DSS SERVICES .
3.2 DSS SERVICE INFRASTRUCTURE .
3.2.1 HARDWARE ........sssceeeeeees
3.2.3 OTHER COMPUTER & TELECOMMS EQUIPMENT ..
3.3 DSS SERVICE ENVIRONMENT.
3.3.1 DSS COMPUTERS....
3.3.2 BUSINESS OPERATING SYSTEMS AND SERVICES ....
4. POCL SERVICE ARCHITECTURE
4.1 POCL STEADY STATE SERVICES
4.1.1 BENEFIT ENCASHMENT SERVICE...
4.1.2 AUTOMATED PAYMENT SERVICE..
4.1.3 EPOSS COUNTER TRANSACTIONS
4.1.3 ADMINISTRATION FUNCTIONS .
4.1.4 POCL INFRASTRUCTURE SERVICES wee
4.2 POCL CONTINGENCY SERVICE
4.2.1 INTRODUCTION......
4.2.2 MAGNETIC CARD READER FAILURE...
4.2.3 BAR-CODE / OCR READER FAILURE...
4.2.4 COUNTER PRINTER FAILURE
4.2.5 ELECTRONIC WEIGH SCALE FAILURE
4.2.6 KEYBOARD FAILURE.........00essse0008
4.2.7 TOUCH SCREEN FAILURE
4.2.8 PC FAILURE - SINGLE COUNTER OFFICE
4.2.9 PC FAILURE - MULTI-COUNTER OFFICE...
4.2.10 NETWORK FAILURE - ISDN CONNECTION
4.2.11 SITE RELATED FAILURE .........
4.3 RELEVANT OPTIONAL POCL SERVICES
4.3.1 BES
4.3.2 APS
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFITOC.DOC Page 7
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.3.4 POCL INFRASTRUCTURE SERVICES
4.3.5 ORDER BOOK CONTROL SERVICE
4.4 POCL SERVICE INFRASTRUCTURE
4.4.1 HARDWARE
4.4.2 SOFTWARE
4.4.3 OTHER COMPUTER & TELECOMMS EQUIPMENT.
4.5 POCL SERVICE ENVIRONMENT .........0+
4.5.1 POCL COMPUTERS ......essesesesneeee
4.5.2 TELECOMMUNICATIONS .........+0
4.5.3 BUSINESS OPERATING SYSTEMS & SERVICES
A. DATA FLOW DIAGRAMSG .........scccssssessesssenesenarerenesenenensnenaenssenseensasesenenanesnens 245
A.1 OVERVIEW
A.2 DETAILED DIAGRAMS...
A.2.1 KEY TO DIAGRAMS
A.2.3 BPS..
A.2.4 EPOSS.
A.2.5 LOCAL NINO LIS
A.2.6 OBCS.
A.2.7 RECONCILIATION.
A.3 DATA DICTIONARY .
B. CALL ENQUIRY MATRIX
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFITOC.DOC Page 8
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
i. ABOUT THIS DOCUMENT
1.1 PURPOSE
Schedule B7 (Authorities’ Agreement), paragraph 2.2, requires that
Pathway will supply BA/POCL with a Functional Specification (FS)
within one week of execution of the concract, for agreement by a target
date of 30 June 1996.
The fundamental purpose of this process is to establish an early level of
agreement between Pathway and the Authorities concerning a.more
detailed level of specification of functionality of the services to be
supplied, and by association, the underlying products from which such
services are derived, such that service and product development activities
can be undertaken with expedition and a high degree of confidence.
Schedule B7 paragraph 2.2 provides that changes to the FS definition
subsequent to agreement will be subject to a process of agreed change
control. The purpose of such change control is to facilitate necessary and
agreed change in a scrutinised and orderly manner, and is neither to
prevent such change nor implicitly vary any party’s obligations under the
contracts.
1.2 STRUCTURE AND SCOPE
This FS is organised in a manner which anticipates the Service
Architecture Design Document (SADD), which is required according to
Clause 401.1 in the Authorities’ Agreement. Pathway proposes that this
FS is developed under change control from its initial form such that it
becomes the SADD itself when satisfactorily complete and detailed and
that it is maintained thereafter as the SADD. In this manner there will be
a complete description and unbroken audit trail of changes proposed and
changes agreed. It is anticipated that the SADD will reach this state in
readiness for July 1977.
Figure 1-1 shows the structure required ot the SADD according to the
terms of the initial agreements.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT1.DOC Page 9
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
1.2.14
Figure 1-1: Required structure of the Service Architecture Design
Document
The scope of the SADD, and hence the target scope of this document, is
therefore the Steady State Service Definition of the Pathway Service as a
whole, divided principally into the two Steady State Service Definitions
applicable to the two Contracting Authorities but with certain topics
which are logically for description at the Pathway Service level.
At early levels of revision of the FS only those parts necessary for the
immediate purpose will be populated. Over time it is anticipated that
material from the body of the document will be abstracted to appropriate
appendices.
Sections 2.1 and 2.2 form a concise description of the Service
Architecture.
CONTRACTUAL BASIS OF STRUCTURE
Where appropriate, the defining clause for an element is shown; for
example, A401.1, D405.2 or P405.4, denoting respectively the
Authorities’, DSS or POCL Agreement clause in question. Similarly the
schedules associated with each element are identified in brackets, in
italics where they are to be produced. Requirements and, in due course,
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT1.DOC Page 10
FUJ00119561
FUJ00119561
Pathway 7 Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Solutions are denoted by Rnnn and Snnn respectively; for example,
R9S1.
The Card Management and Payment Authorisation Services embrace a
number of second order services; for example; the BPS Management
Information Service. These are grouped as common service elements
within the DSS Service Architecture.
1.2.2 PFI SERVICE LEVEL COMPONENTS
It is in the nature of the total service solution that the end-to-end aspects
of the Benefit Payment Service (BPS) are for specification at the top level
of Service Architecture. The Card Management and Payment
Authorisation Services (CMS, PAS), together with several supporting
services, are defined within the DSS Service Architecture, while the
Benefit Encashment Service (BES) forms part of the POCL Service
Architecture. ;
In addition certain aspects of the security architecture are for
specification at the top level of the Pathway Service Architecture.
In order to assist understanding of the operation of the services, this
document provides information about the products on which they are to
be based. -Pathway reserves the right to modify these underlying systems
in order to meet its obligations under the agreements.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT 1.DOC . Page 11
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
2.1
PFI SERVICE ARCHITECTURE
PFI SERVICE INFORMATION FLOWS
Figure 2-1 shows the Pathway-centric view of the information flows
between Pathway and entities external to Pathway. Many of the
information flows are program-based, but some are paper- or voice-
based. For example:
A customer ;aying a bill is served at the counter. Pathway inpayment
services will effect the logical. completion of the information flow by
notifying both the POCL client and the POCL transaction accounting
system TIP.
A customer collecting his benefit will be able to do so because CAPS has
sent a payment authorisation which Pathway has made visible to the BES
application. Pathway will subsequently complete the logical information
flow by notifying CAPS that it was paid and notifying TIP that the post
office made the payment.
Similarly, a benefit customer who has lost his benefit card will report this
by telephoning the Pathway CMS help desk. The CMS help desk will
complete the logical information flow by arranging for a Pick Up Notice
(PUN) to be sent by Royal Mail to his home address, and a replacement
- card to be sént by Royal Mail to his nominated post office.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT2.DOC Page 12
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Benefit Book Help
ESNCS Stops, Responses Desk
calls
POC
Clients
huOue
r "
R
> TIP
Differences
IM I
CAPS
Figure 2-1: Pathway Service information flows
2.2 PATHWAY SERVICE COMPONENT RELATIONSHIPS
Figure 2-2 shows how the total Pathway service is divided into its major
service elements and the relationships between them and the program-
based entities within DSS and POCL.
It also shows how the principal program information flows referred to
above are mapped between the service elements. For example:
The benefit encashment flow starts at CAPS with a payment
authorisation which PAS transfers to TMS and BES, having taken
information about the customers who can collect it from CMS. BES and
TMS then control the payment process. The post office accounting
routines will similarly notify TIP of the payment.
The bill payment flow proceeds from the 4?$ or EPOSS service to the
recipient POCL client. The post office accounting routines within
EPOSS will notify POCL’s TIP system of the transaction.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT2.DOC Page 13
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version:. 3.0
Date: 22/5/96
anes. & . I cms
I I I
ve TMS _ ]
ss. I BES “aps EPOSS I
t i 14
Figure 2-2: Pathway major service component relationships
2.3 BPS END-TO-END SERVICE DEFINITION
2.3.1 PFI RELATIONSHIPS
The Benefit Payment Service (BPS) is defined as the end-to-end service
provided by the combination of Benefit Encashment Service (BES),
Payment Authorisation Service (PAS) and Card Management Service
(CMS) (Schedule A1). As such it is an abstraction comprising a
combination of services which themselves are part of both the. DSS and
POCL Service Architectures.
The BPS is unique within the PFI architecture: the DSS is the only POCL
client whose host processing falls within the procurement boundary as
shown in Figure 2-3.
Printed: 22/05/96
C:\FINALPRN\PFISCT2.DOC
COMMERCIAL-IN-CONFIDENCE
Page 14
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
N Other POCL I Poct Client
‘ clients Host functions
Transaction
Management
Service
Office
Platform
Service
Benefit Payment Service-—————_»
POCL Infrastructure Services
2
a
<=. oo
Foaslhime
Figure 2-3: The end-to-end Benefit Payment Service
2.3.2 A WALK-THROUGH OF BPS
The physical and logical mapping of the Benefit Payment Service is
shown below in Figure 2-4. In essence BPS uses the DSS Service
Architecture for back-end processing and the Transaction Management
Service (TMS), the Office Platforii Service (OPS), the EPOS Service
(EPOSS) and BES elements of the POCL Service Architecture as its route
to customers.
2.3.2.1 DSS SERVICE ARCHITECTURE
Payment authorisation and card traffic originates and terminates at DSS
mainframe systems running the CAPS applications. These CAPS servers
a.e located on four sites, Washington, Livingston, Norcross and
Swindon.
The CAPS Access Service (CAS) is implemented in secure partitions
within the DSS mainframes themselves. It handles transfers of payment
authorisation and card management traffic in both directions between
the CAPS application and the Pathway central servers located at two
sites; Bootle and Wigan. Pathway assumes responsibility for the traffic
from the CAPS-CAS interface.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT2.DOC Page 15
FUJ00119561
FUJ00119561
Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
Pathway
The CAS performs basic checking and record and data compression
functions.
Transfers over the high speed wide area network connections between
DSS and Pathway are encrypted.
PAS and CMS are logically separable services implemented in ORACLE7
on Sequent Dynix platforms. At this level also are the linked Help Desk
telephony platforms.
Open VME CAPS DSS Service Environment
Mainframe oo
Sequent/Dynix
Central Servers
oes oo HelpI DSS Service
PAS/CMS RY
: ~ Desks:I Infrastructure
PAS/CMS Agent
L Transaction
Wholesale Broker Management
Service
Compaq/NT
Correspondence
Servers
PC/NT
Post Office
Counter
Systems
Office
Platform
Service
POCL Infrastructure Services
Figure 2-4: Mapping of BPS on to Service Architectures and platforms
2.3.2.2 POCL SERVICE ARCHITECTURE
The Correspondence Servers are implemented as four groups of large
servers, two groups per Pathway central site with a number of servers per
group. Interaction between the Central Services layer and the
Correspondence Server layer is through a PAS/CMS Agent program
which acts as a real file manager. This manages the transfer of data
between the ORACLE7 and Riposte messaging system reformatting data
as required.
The Wholesale Broker program allows Agent applications to treat the
community of Correspondence Servers as a single entity by routing
transactions to and from correspondence servers. Agent programs
include those handling the traffic with POCL and POCL Client systems.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT2.DOC Page 16
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01 I
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
This level also supports post office to post office transactions, in
particular those required for “foreign payment” processing.
The Riposte messaging system runs on both the Correspondence Server
and Post Office layer platforms handling the communications traffic
across the ISDN connections in co-operation with Windows NT.
Riposte acts as a distributed database, maintaining replicas of records
between the central correspondence servers and the post office counter
systems.
Benefit authorisation transfers down to the counters are protected over
this wide area connection by digital signature techniques.
Riposte supports application oriented interfaces to the EPUSS
application, and in turn to the several counter service applications of
which BES is one.
Sensitive benefit data stored on hard disk \irhin the post office counters
is protected by encryption.
2.4 PFI SECURITY ARCHITECTURE
2.4.1 SECURITY STRATEGY
Pathway will establish an infrastructure that will minimise and control
liabilities to itself and DSS and POCL as specified in R698..Pathway’s
aim is to be compliant with BS7799.
Pathway’s security infrastructure will cover:
Agreement of a security policy
Allocation of security responsibilities
Security education and training
Security incident reporting
Physical security control
Virus control
Business continuity
Control of proprietary software
Safeguarding DSS and POCL records
Information classification
Compliance with Data Protection and other legislation
Information exchange control
External contractors and Pathway’s sub contractors and suppliers
Compliance with security policy
eoceeoece eee eee oe
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT2.DOC Page 17
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
e Management of fraud and risk during service operation
Three of these elements
e Business Continuity
e Fraud Risk Management
e Data Protection legislation compliance
are of particular impoitance at this level of revision and are discussed in
more detail below.
2.4.2 SECURITY DOCUMENTATION
Pathway will develop full operational documentation in accordance with
its Quality Management System (QMS). The QMS system will be
submitted for Is09001 accreditation: .
e Security Policy
e Standards
e Audit
¢ Procedures
2.5 BUSINESS CONTINUITY
2.5.1 CONTINGENCY
Pathway will develop and agree with DSS and POCL the contingency
arrangements that will be used to ensure continuity of service, as
described in R830:
1. Pathway will ensure that all services are supported by Contingency
Plans including Fallback Transactions that will minimise or negate the
impact of failure in any part of the services.
2. Pathway will ensure that the Contingency Plans for each service are
compatible with an overall Service Continuity framework.
The Contingency Plans will be based on Impact and Risk Assessments
agreed between Pathway and DSS and POCL
3. Ownership of all contingency actions will be identified.
4. The Contingency Plans will include activation procedures and time
periods within which the contingency measures will be activated.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT2.DOC Page 18
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
5. The Contingency Plans will include a testing strategy with two distinct
parts:
Initial testing on implementation and deployment
Regular testing
6. The Contingency Plans will include the following:
Prevention measures
Preparedness measures
Contingency measures
Recovery of normal service
Change control procedures
Contact lists
Service levels - Pathway will be liable in accordance with schedule
BO3
7. The Contingency Plans will be subject to joint review by Pathway, DSS
and POCL -
2.6 FRAUD RISK MANAGEMENT
2.6.1 INTRODUCTION
The Fraud Risk Management (FRM) service will deal with the
identification, monitoring and management of encashment fraud within
the Benefit Payment Service and the POCL Strategic Infrastructure.
Pathway’s policy is to identify and minimise the risk of fraud within the
Pathway system. However, Pathway recognises that the threat of fraud
incidents exists inside and outside Pathway’s responsibility.
Pathway’s strategy is to identify high risk situations and adapt systems as
necessary to:
e Minimise fraud exposure within the Puwuway solution
© Provide an information service to DSS and POCL to aid fraud
investigation and to minimise fraud.
The information provided will be:
e Trend and pattern analysis for DSS to aid identification of fraud risk
and appropriate mitigation actions
e Information to aid in the investigation of actual fraud incidents
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT2.DOC . Page 19
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
e Certification relevant to operation of the system as required by PACE
Act, 1984 and equivalent legislation as required by the territory of
operation
e Information for the investigation of system boundary related incidents
and trends; for example, counter staff-related fraud with the aim of
developing improved procedures
e Analysis of incidents and trends within Pathway’s immediate control,
to improve its systems
2.6.2 FRAUD RISK MANAGEMENT SERVICE ELEMENTS
The FRM service will comprise two core elements:
e A management information system, to analyse trends, fraud losses and
to profile data patterns. This is part of Pathway’s own MIS systems.
e A fraud monitoring system, to profile abnormal or irregular
encashment patterns and identify potential fraud incidents, as required
by R895, see below
2.6.2.1 MANAGEMENT INFORMATION SYSTEM
The MIS will provide both standard and ad hoc reports. Key areas of
information which will be captured and analysed include:
e transaction volumes, values
e location
© verification procedures
e timing of encashment
© customer details
Standard key reports will be provided at regular intervals, to be agreed,
for review within Pathway and with DSS and POCL.
2.6.2.2 IRREGULAR ENCASHMENT PATTERNS
R895 requires that the PFI service will be capable of monitoring irregular
encashments and reporting on irregular encashments to DSS. Information
will be shared with POCL audit/Security/Operations when it relates to a
post office.
Ad hoc analysis and reports will be provided and will include specific
fraud analyses and encashment monitoring, in order to monitor the
movement and use of cards to detect exception conditions and possible
fraudulent use for example :
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT2.DOC Page 20
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
© Post offices with high levels of fraud incidents or losses, foreign
transactions, manual keying, casual agents
e Customers with high levels of lost/stolen cards, non-received PUNS,
changes of nominated offices
Specific irregular encashment patterns for reporting are to be agreed with
DSS and POCL, to include for example:
1. Non encashment of a means tested benefit for a period of (4 weeks)
2. Non encashment of a non means tested benefit for a period of (6
weeks)
3. Change of nominated post office and encashments for a period of (6
weeks), where there is no notification of change of address being
received by CMS from CAPS
[DN: This may need to distinguish cases where the change of
nominated post office is not accompanied by change of address.]
4, High Risk transactions indicating a potential exposure to fraud, for
example:
e Foreign encashments
© Casual agent encashment
e Regular casual agent encashmént (4 consecutive weeks)
e Multiple encashments (will depena on period of validity - to be
defined)
e Any combination of the above
5. Any encashment made or attempted where a stop is in operation
6. Any encashment of a payment where a subsequent loss report is
received
7. Presentation of a non genuine card
8. Apparent presentation of a duplicate card (both to be cancelled
immediately)
9. Any attempted keyed transactions out of specified service hours
[DN: This may need to distinguish legitimate counter activity
undertaken outside of the hours of service cover.]
10. Multiple keyed or telephone authorised transactions by clerk and
outlet, where there is no report of service or equipment failure
(contingency transactions at a level anycning above the agreed service
efficiency levels)
11. Any transactions at a non-live post office i.e. one reported as
temporarily out of commission
12. Usage of duplicate clerk identification devices or numbers (note that
both must be cancelled immediately)
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT2.DOC Page 21
FUJ00119561
- FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
2.6.3 DATA PROTECTION ACT, 1984
R938 states that:
e Pathway is responsible for ensuring that any information supplied
under the Data Protection Act 1984 is accurate and that assurances
can be given as to the integrity of that information.
e Pathway is responsible for delivering any information requested under
the Data Protection Act 1984 to the requesting body, Person or DSS
as appropriate,
The Data Protection Act 1984 became law from 11/11/87, Pathway will
ensure that all subsequent alterations and reviews to this law are
integrated and adhered to.
Pathway will record all written requests for a data protection print from
a Customer, representative or DSS within forty (40) days of receipt of
the request, and deal with queries raised within a timescale to be agreed
with the DSS and POCL.
All information provided under the Data Protection Act 1984 will be
made available to facilitate inspection.
Details of a request and response made under the Data Protection Act
1984 will be retained consistent with the Data Protection Act 1984
requirements.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT2.DOC Page 22
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
3. DSS SERVICE ARCHITECTURE
3.1 DSS STEADY STATE SERVICE
3.1.1 CARD MANAGEMENT SERVICE
3.1.1.1 INTRODUCTION
This section describes the processes within the Card Management
Service (CMS) and how BA, BA Customers and POCL will use the
service as part of the end-to-end Benefit Payment Service (BPS). The
CMS is required to be available 24 hours a day every day of the year.
The CMS is a central computer service that will store details of all BA
customers who are entitled to a benefit payment card. It will maintain a
cardholder record for each customer, with an ‘greed amount of
historical information regarding card activizy, accessible for reporting
and enquiries.
The CMS manages the production; automatic renewal, issue and
distribution of magnetic cards, Pick Up Notices (PUNs) and Temporary
Tokens. CMS also manages enquiries from the CMS Help Desk for
reports of lost, stolen and damaged cards.
Cards and Temporary Tokens remain the property of the Secretary of
State and can only be used for bencfit payment unless otherwise
authorised by the Secretary of State.
Pathway’s strategy for. the migration from magnetic cards to integrated
circuit cards is not described at this level of specification.
CMS provides the Pathway Payment Authorisation System (PAS) with
cardholder details required for payment processing including cardholder
verification details.
Within this document each major aspect of the service is presented from
the view point of BA, POCL and the Customer.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 23
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
3.1.1.1.1 OVERVIEW DIAGRAM OF THE CARD MANAGEMENT SERVICE
Maintain/Enquire Generate
de Cardholder Details I Card Orders I Pr] Produce Cards
CAPS l
via CAS
\ ’ Fort Office
Distribute Cards
(Royal Mail) I —pe
cs J.0. BLOGGS
PAS
BES Fee
Address
>
Phone Calls
from Lost and Stolen Produce PUNs
Customers
Distribute
PUNs
fs CMS (Royal Mail)
/ Help Desk
Figure 3-1: The Card Management Service
3.1.1.2 INTRODUCE NEW CARD HOLDER
- On receipt of instructions from the BA, via the CAPS Access Service — =:
(CAS), CMS will add new cardholders to the system. The BA will
ensure that correct postal addresses including post codes are used.
The system will'validate the new cardholder details received from BA for
format in line with the BA/POCL Service Interface Definition. All valid
records will be added to the CMS. Cardholder records that fail
validation will be returned to BA via CAPS for resolution.
3.1.1.3 MAINTAIN CARDHOLDER DETAILS
On receipt of instruction from the BA via CAS, CMS will apply
amendments to personal details. As a result of these changes it may be
necessary to issue a new card.
A new card will automatically be issued where a cardholder has a change
of name, for example, the change from maiden name to married name,
change of nominzted post office, or English to Welsh and vice-versa.
CMS will forward changes to PAS for use during payment processing.
Printed: 22/05/96 , COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 24
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
3.1.1.4
3.1.1.5
3.1.1.6
MAINTAIN CARD STATUS
During the life of a card its status will change. CMS will maintain an
audit trail to show the lifecycle of the current and previous card
including:
card ordered
card received at post office
card activated
card suspended, carried over for a card reissue
card unsuspended
card terminated and reason:
e card reported lost
card reported stolen
card reported damaged
card reported found
card reported destroyed
card uncollected
card expired
card returned
card not received at the post office within due time
card verification failure at counter
© card impounded
eeoeeec ee ee
RECORD CARD HOLDER NO LONGER ELIGIBLE FOR BENEFITS
The objective of this process is to record that a card holder is no longer
eligible for benefit and will not require 2 card in the future.
On receipt of an instruction from CAPS, CMS will validate notifications
and return failures to CAPS.
Accepted notifications will be applied within CMS. Where a current
card exists and is not expired CMS will prevent its use for future
encashment. The card will be designated ‘dormant’ and stopped on the
nominal expiry date unless new personal details are received
beforehand. In this case the card will be reactivated.
THE CARD
The card design will be subject to approval from the Secretary of State.
The design will allow for different liveries, will conform to financial
standards and include a number of security features, e.g. hologram and
indent printing. The card will include a signature stripe and will be
embossed with the following information:
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE .
C:\PFISCT3A.DOC Page 25
FUJ00119561
FUJ00119561
» Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
va Date: 22/5/96
e a6 digit unique Primary Account Number (PAN) incorporating the
NINO, in a 19 digit field with three spaces
e surname and initials of the cardholder
¢ cardholder’s full NINO
© card expiry date - three years from issue
e card issue number
Excluding the signaturc, the above items will also be held within the
magnetic stripe of the card together with a security value which is
validated against system held data during usage.
The card will include pre-printed information:
~ © a freepost address for return of cards under exceptional circumstances;
for example, card found by a member of the public
© a message in accordance with R962
Where the customer’s nominated post office is a Welsh postal address,
information printed on the card will be in both English and Welsh. ©
3.1.1.7 CIRCUMSTANCES WHEN A CARD ORDER WILL BE
GENERATED
Pathway will automatically generate a benefit payment card under the ~ oe
following circumstances:
e new cardholder added to the system
e card reported lost or stolen
e card reported as damaged
e change of cardholder name (ex CAPS)
© card due to expire
e cardholder reinstated on system and has no active card
e changed nominated post office from England to Wales and vice versa.
[DN. will Welsh I English changes take place on change of office or when
current card expires?]
3.1.1.8 CATERING FOR SPECIAL NEEDS GROUPS
The card will carry a tactile mark to allow the blind to distinguish it
readily.
3.1.1.8.1 BA VIEWPOINT.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC. Page 26
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
. Date: 22/5/96
3.1.1.9
3.1.1.10
In order for Pathway to manufacture cards selectively for the blind, BA
will be need to identify such customers via CAPS.
[DN: Will all cards carry the blind tactile marker?]
. CARD PRODUCTION
Pathway will operate an ‘Urgent’ and ‘Nc.i Urgent’ timetable for card
production and distribution which is:
e Urgent orders:
new cardholder
replace lost or stolen card
replace damaged card
change in personal details
reinstated customer, no active card
ee RK
e¢ Non-urgent orders:
* reissue card on expiry
CARD PERSONALISATION AND DELIVERY TO NOMINATED
POST OFFICE.
Pathway will generate personalised magnetic cards to the appropriate
design as specified by BA. On completion of the card production
process, cards will be batched by customer name within post office.
Royal Mail will ensure secure delivery into post offices where their
receipt is recorded on CMS and validated against expected arrival.
In the event that the Royal Mail service is disrupted by a postal dispute
or other unforseen circumstances, Pathway will employ alternative
carriers.
For the majority of cards, Pathway propose to use sealed cardboard
trays with lids for the delivery of cards to post offices. However, where
a batch for a post office contains fewer thai. cen cards, the cards will be
delivered in a secure envelope.
Each batch will contain the post office address, the batch ID and number
of cards in bar code format. This format will be recognised by CMS
when booked on to the system at the post office.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 27
FUJ00119561
FUJO01 19561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Pathway will maintain within CMS an audit trail of all cards produced
from initial request via CAPS, or the help desk, through to delivery and
pick up by the customer at the post office counter.
3.1.1.10.1. CARD LIVERIES/ LOGOS
The Pathway solution will allow for mult‘ple card liveries within the
system. However, a customer will have only one active card type at any
one time.
3.1.1.10.2 =POCL VIEW POINT
Cards will be delivered to the post office by Royal Mail. The post office
will be responsible for the receipt, recording within CMS and secure
storage of cards prior to issuing the card to the customer on pick up.
The supporting clerical activity and sequence of events is fully described
in the Counter Procedures.
3.1.1.11 THE PUN
The PUN will contain the cardholder’s name and nominated address.
The PUN will contain a bar code which includes a Card Activation ~
Number (CAN) which is matched against system held information
during card activation.
The PUN will contain pre printed information for the customer in
English, Welsh and a number of other languages agreed with the BA.
[DN: Agreement on PUN languages required.]
The PUN communication may also contain information notices and the
like.
[DN: Discussion and organisation of such collateral material is required
from time to time]
Pathway will produce a PUN under the following circumstances:
e all new cardholders
¢ collection of » replacement card having reported to the CMS help
desk that his existing card is lost or, stolen, damaged or his personal
details have changed.
© on the third consecutive keyed entry of a damaged card’s details
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC. Page 28
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification. Version: . 3.0
Date: 22/5/96
e reinstated cardholder, no active card
» In all circumstances where a PUN is produced the card cannot be
collected without the PUN being presented.
Where a customer fails to collect the card within 40 days a second
reminder PUN will be sent.
Where a customer has lost, not received, or reported his PUN stolen and
the card is available for collection, there are two scenarios to be
considered:
The PUN in question is the first PUN. In this case the customer will
receive a PUN reminder which can be used to collect the card. The
reminder will have a new CAN.
The PUN in question is the second, the custon.er not having received
the first one either. In this case the custom 2r should call the CMS help
desk which will reorder a third PUN, with anew CAN. On production
of a second PUN reminder, Pathway proposes that details of the
transaction are sent to BA via CAPS.
(DN: Process to be agreed.]
3.1.1.12 DELIVERY OF PUN TO CARDHOLDER’S NOMINATED ADDRESS
Pathway will inform the authorised person that the card is available for
collection by issuing a PUN to the cardholder’s nominated address via
the Royal Mail. In the event of disruption, a similar contingency to that
described above will be invoked.
The delivery of the PUN will be synchronised with the delivery of the
card to the cardholder’s nominated post office, to ensure that the card is
available at the post office for collection by the customer.
The PUN will be accompanied by a mandate form to allow a customer
to use an agent without having to cc!lect one from the post office
3.1.1.12.1 BA VIEWPOINT
Where a cardholder has no fixed abode, the cardholder’s PUN can be
delivered to the person’s local Benefit Office as per information
provided by BA to Pathway via CAPS,
Each BA office will be required locally to:
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 29
FUJ00119561
FUJO0119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
¢ maintain a record of all customers who require this service,
e operate and maintain procedures for the issuing of PUNs to such
cardholders.
(DN: DSS to allocate a nominated post office for cardholders of no fixed
abode. Procedures for subsequent changes to be agreed with Pathway]
3.1.1.12.2 CUSTOMER’S VIEW POINT
The customer will collect his card from his nominated post office. In
order to collect his card, the customer will present either the PUN or his
old card (when current card expires), together with an independent
means of identification.
Pathway will produce a PUN for the following Pick Up types:
e all new cardholders
e collection of a replacement card having reported to the CMS help
desk that his existing card is lost or, stolen, damaged or his personal
details have changed. - a
e on the third consecutive keyed entry of a damaged cards details
e reinstated cardholder, no active card
The PUN will contain personal details including, name, NINO, address
and security information which will be matched on the system during
the card activation process.
In addition to the personal details contained on the PUN, Pathway will
pre-print supporting information in English, Welsh and an agreed
number of other languages.
[DN: Agreement on PUN collateral languages required.]
Where a PUN is produced as defined above, the customer will not be
allowed to collect his card without its presentation at the post office. If
for any reason the customer loses his PUN, he will need to request a
replacement via the CMS Help desk.
3.1.1.13 CIRCUMSTANCES WHEN PUN WILL BE GENERATED
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC. Page 30
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
3.1.1.14
3.1.1.15
3.1.1.16
The PUN will contain the cardholder’s name, nominated address and
NINO. To improve security and minimise the risk of fraud, the PUN
will be encoded with a Card Activation Number (CAN). This CAN will
be matched against system held data during card activation. The PUN
will contain pre-printed information in English, English and Welsh, and
English and other minority languages.
Pathway will generate a PUN under the following circumstances:
e all new cardholders,
e card reported lost or stolen to the CMS Help Desk, or his personal
details have changed.
e on the third consecutive keyed entry of a damaged card’s details
e reinstated cardholder, no active card
COLLECT AND ACTIVATE CARD
The object of this process is to record autliorised collection of the card
and to activate that card to enable subsequent collection of payments.
The process also ensures that outstanding payments are allocated to the
newly-issued card and no longer collectable by presentation of the old
card. This is to ensure continuity of payment collection.
Customers will present the PUN at their nominated post office with an
independent means of identification during card pick up.
The supporting clerical activity and sequence of events is described in
the Counter Procedures in Section 4.
CUSTOMER UNABLE TO COLLECT CARD
Pathway will handle this eventuality according to whether the customer:
e is replacing a card routinely
e is replacing a card following card loss or damage
e is newly enrolled into the benefit system
REPLACEMENT OF EXISTING CARD ON CARD EXPIRY
When a card is within six weeks of its expiry date, Pathway will
automatically generate.a replacement card which will be available for
pick up at the cardholder’s nominated post office on the presentation of
the card which is due to expire.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC . Page 31
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
3.1.1.17 AUTOMATICALLY REPLACE DAMAGED CARD
The CMS will automatically record and analyse the number of
consecutive keyed entries of card details when the card is being used to
encash benefits at the post office.
On the third consecutive manual keying of card details, thé system will
automatically generate a replacement caru and PUN for the customer.
The card will be delivered to the customer’s nominated post office ready
for collection on the presentation of a PUN
The damaged card will continue to be used until the replacement card is
available.
3.1.1.18 REPLACE DAMAGED CARD
When a card has been reported damaged to the CMS help desk by the
customer, a replacement card and PUN will be generated. The card will
be delivered to the customer’s nominated post office, ready for
collection on the presentation of his PUN.
The damaged card will continue to be used until the replacement card is
available. The damaged card will be required to be presented with the
PUN when the new card is collected. Te
3.11.19 REPLACE LOST OR STOLEN CARD
When a card has been reported lost or stolen to the CMS help desk, an
urgent card order and PUN will be produced The card will be delivered
to the customer’s nominated post office, whilst the PUN will be
delivered to the customer’s address supplied by BA.
3.1.1.20 REPORT NON-ARRIVAL OF BATCH OF CARDS AT POST OFFICE
The object of this process is to detect non-arrival of a batch of cards at
the post office within the designated time period (based upon _
anticipated production and delivery schedules) and to instigate action.
Whenever a card order is placed within the CMS, the card production
and delivery status is monitored through to recorded receipt at the post
office.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 32
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
The system will automatically and immediately suspend any card not
received at the nominated post office within three working days after
expected arrival.
CMS will create an exception record for presentation to the CMS Help
Desk so that the late delivery can be investigated. The exception event
reporting will be repeated each day until the batch is booked in, the
batch is cancelled, or the allowed margin for delivery has expired.
The CMS Help Desk will investigate and either extend the margin or
cancel the batch of cards. Cancelling the batch will automatically
include the setting of each individual card status to lost. The help desk
may reorder the batch of cards after investigation.
3.1.1.21 INHIBIT CARD ON FAILURE TO COLLECT
The purpose of this process is to inhibit ca: ds not collected by the
customer within a predetermined number of days (currently 56) from
the date of issue.
BA will define the period within which a customer must collect a card.
Failure to collect will lead to cancellation of the card and.an exception
report to BA.
The supporting clerical process is described in the Counter Procedures.
CMS card status will be available to PAS for use in payment processing
such as enrichment.
CMS will report non-collection to BA via CAPS.
3.1.2 CARD MANAGEMENT SERVICE HELP DESK
3.1.2.1 INTRODUCTION
The CMS help desk will provide a single point of contact for all
enquiries relating to benefit cards and PUNs. It provides separate
telephone numbers for BA, POCL staff ana for BA customers. In
accordance with the Welsh Language Act 1993 a service (including
separate telephone line) will be provided to Welsh speaking customers.
The majority of calls to the CMS help desk will be from members of the
public reporting lost, stolen or damaged benefit cards and PUNs,
although authorised BA and POCL staff will also require access to the
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 33
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
3.1.2.1.1
help desk in certain situations. See Appendix B for a full list of enquiry
types
As an integral part of the authentication process for the validation of
callers, BA and POCL staff calling the help desk will be asked to answer
verification question(s). This security measure will ensure that only those
members of staff nominated by the authorities will have access to the
help desk services.
Although the NINO provided by the customer will be the key by which
the help desk will access the card and payment management systems, the
caller will be.asked a further verification question, to ensure he is the
authorised cardholder.
Pathway’s internal access to the Card Management Service via the help
desk will be strictly controlled. Only staff with the appropriate security
level will have access to, and have the authority to amend the status of
card and PUN details. All status changes will be subject to a complete
audit trail.
OVERVIEW DIAGRAM OF THE CMS HELP DESK
CMS HELP DESK
BA STAFF
CMS HELP
. DESK
~~
BA CUSTOMERS
POCL
COUNTER %
STAFF &
Figure 3-2: The CMS Help Desk
All calls, will be answered to agreed SLA timescales and attract local call
rates. For contingency purposes the help desk will be provided at two
sites.
The CMS help desk will be manned to deal with calls 24 hours a day
every day of the year.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 34
FUJ00119561
FUJ00119561
Pathway . Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
The CMS help desk will also deal with calls from members of the public
who wish to report finding a card or PUN.
[DN: The location to which found cards are to be returned is to be
agreed.]
In the majority of circumstances a new card and PUN will be ordered for
the customer. Details of cards returned <> the help desk will be recorded
and forwarded to the appropriate BA office.
[DN: This process to be agreed.]
3.1.2.2 BENEFIT AGENCY CUSTOMER’S VIEWPOINT
The CMS help desk will provide BA customers with single point of
contact for reporting lost, stolen or damaged benefit payment cards and
PUNs. Contact with the help desk will be via-the telephone.
ge
3.1.2.2.1 CALLER VERIFICATION
On contacting the help desk the customer will be‘asked to provide his
National Insurance Number (NINO) or Primary Account Number
(PAN). This will enable the help desk operator to access the customer’s -
details. To verify the caller is genuine, the help desk will ask the
customer verification question(s) from information contained within his
personal details. Only on successful clearance of this validation process
the help desk will act on instructions from the customer.
If the customer cannot provide either the NINO or PAN, the help desk
will have a search facility to access customer details using surname and
date of birth, or surname and first line of address and post code.
If when the customer details are accessed, the National Sensitivity
Indicator is displayed, the call will be dealt with at the appropriate level.
[DN need ta confirm procedures. Remova! .f NSI from CAPS records is
pending.]
3,1.2.2.2 REPORT LOST/STOLEN CARD
Wher a customer reports a lost or stolen card, the help desk will update
the status of the card to reflect lost/stolen, immediately triggering a
number of events which lead to the update of the system preventing any
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC . Page 35
FUJ00119561
FUJ00119561
I
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
further benefit encashments against that card. At the same time, the
CMS help desk arranges the issue of a replacement card and PUN.
There may be a reason why an automatic reorder of a card may not be
desirable at the time the loss/theft is recorded. The order may need to
be delayed pending the outcome of investigations by BA and the
replacement card and PUN ordered at a later date.
(DN: Process for such supervision of reorder to be discussed and agreed.]
3.1.2.2.3 REPORT DAMAGED CARD
The help desk will register the card as damaged on the system. There is
no requirement to inhibit use of the card, pending collection of its
replacement.
The help desk will order a replacement card for collection when the
customer next attends his nominated post office. The damaged card will
be handed in on collection of the new card.
3.1.2.2.4 REPORT NON RECEIPT OF PUN
Where the customer cannot present his PUN at the counter to collect his
benefit card because of non receipt or loss he will be referred to his
benefit office. - a
3.1.2.2.5 REPORT CARD NOT AVAILABLE AT NOMINATED POST OFFICE
Where the customer reports his card was not available for collection at
the post office on presentation of his PUN, the help desk will check the
card status on CMS and where necessary cancel the original card and
order a new card and PUN for the customer. If the customer has
payments due, he will be referred to his benefit office for a temporary
token.
3.1.2.2.6 REPORT CARD/PUN FOUND PREVIOUSLY REPORTED LOST
The help desk will record the call, but once the status of a card or PUN
is updated to reflect ‘lost’ they cannot be re-activated. A new card/PUN
will have previously been ordered for the customer as the result of the
loss report.
[DN: confirm cus:omer to be advised to post card back to the Freepost
address on the reverse of the card.]
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 36
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
3.1.2.2.7 ENQUIRE UPON CARD/PUN STATUS
The help desk will provide information to customers on the current and
amended status of cards and PUNs; for example, card/PUN ordered,
card/PUN issued, card reported lost.
3.1.2.2.8 EXCEPTIONS:
There are a number of situations where the help desk cannot provide
information to callers. These include:
© customer not known on the system
¢ caller cannot provide NINO, PAN, date of birth, or first line of
address and post code
e caller fails verification question(s)
¢ the caller disconnects the call
[DN: Number and type of questions and su_cess criteria to be agreed.}
3.1.2.3 BENEFITS AGENCY’S STAFF VIEWPOINT
Contact by authorised BA staff to the CMS help desk will be via the
telephone. BA staff will be required to provide each individual
customer’s NINO or PAN. This will enable the help desk to access the
customer’s personal details. Any changes to card and PUN status
records will be subject to a full audit trail.
[DN: Operation of process required at R731 (stop direct from a BA
office) as distinct from CAPS stops, to be discussed and agreed.]
3.1.2.3.1 CALLER VERIFICATION
To ensure that only those members of staff authorised by BA can use the
help desk services, all callers will be required to complete a verification
process. This will involve the help desk asking the caller security
questions; for example, office identification number.
(DN: Is the callers identity to be recorded on the system?
How and how often will the verification process change?]
3.1.2.3.2 CAPS/CAPS ACCESS FACILITY NOT AVAILABLE
If the CAPS/CAPS Access facility is not available to convey urgent status
changes to cards and PUNs, the CMS help desk will take instructions by
telephone from authorised BA staff and make the necessary changes.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 37
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
For a full description of each status change see section 3.1.1, Card
Management Service.
(DN: Is this process required?]
3.1.2.3.3 SUSPEND A CARD
Suspending a card will prevent the customer encashing further payments
using their card until the suspension is removed. (PUNs cannot be
suspended.)
3:1.2.3.4 UNSUSPEND A CARD
Removing a card suspension will allow the customer to collect benefit
payments using their card. -
3.1.2.3.5 TERMINATE A CARD
Terminating the card for whatever reason will prevent any further
encashments using that card, from the specified termination date and
time.
[DN: Is there a requirement to terminate a card at a point in time in the
near future?]
3.1.2.3.6 ENQUIRE UPON CARD/PUN STATUS
The help desk will respond to enquiries on current and previous card
and PUN status from authorised BA staff. For a full description of the
status help on the system See section 3.1.1, Card Management Service.
Enquiry responses will include the following details:
e PAN
e NINO
° card status
° previous card/PUN status
* previous card/PUN date status changed
3.1.2.3.7 CALLS ON BEHALF OF BA CUSTOMERS
BA staff can report the following situations on behalf of their customers:
e lost, stolen or damaged cards and PUNs
© non-received PUN
e card not available at the post office
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 38
FUJ00119561
FUJ00119561
\
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
© report card/PUN found previously reported lost
Descriptions of these processes are included in Section 4, BA Customer’s
Viewpoint
3.1.2.3.8 EMERGENCY ORDER BATCH CF TEMPORARY TOKENS
BA can order one or more batches of Temporary Tokens via the CMS
help desk in an emergency situation where an office is running low
unexpectedly. (Normal steady state ordering of temporary token
batches will be via the CAPS program interface.)
The help desk-will verify the caller, take the order and send it to the
token producer. All orders will be event logged and subject to a full
audit trail. All instances of non receipt of orders within the
predetermined timescale should be reported to the help desk.
[DN: Secure process for such telephone ord#?s'to be agreed. Process to be
restricted to CAPS personnel.]
3.1.2.3.9 TERMINATE TEMPORARY TOKEN(S)
This process will allow authorised BA staff to terminate use of a
temporary token via the help desk. The temporary token ID number .-
will be required to process the termination. Where a report of a non
receipt of a batch of temporary tokens is received by the help desk the
termination process has the capability to issue bulk stops of temporary
tokens; for example, whole batches, or tokens within a specific range.
3.1.2.3.10 I EXCEPTIONS
There are a number of situations where the help desk cannot provide
information to callers. These include:
e the caller fails the authentication check
e caller cannot provide NINO, PAN, date of birth, or first line of
address and post code
e the customer is not known to the system
3.1.2.4 POCL COUNTER CLERK’S VIEWPOINT
The Post Office counter clerk contact to the help desk will be via the
telephone.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 39
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
3.1.2.4.1 CALLER VERIFICATION
In order to authenticate the caller, the help desk will ask the clerk to
answer verification questions.
3.1.2.4.2 NON ARRIVAL OF BATCH OF CARDS
CMS will detect the non-arrival of a batch of cards at the post office
within the designated time period, based upon anticipated production
and delivery schedules.
CMS will suspend the cards in a batch that has not arrived within a
predetermined time according to the class.pending the outcome of
investigations. The help desk will act as the focal point for contact with
the post office. Should the batch arrive late the suspension can be
removed (the help desk may extend the margin if required). However,
the help desk can cancel and reorder the batch of cards if necessary.
3.1.2.4.3 ACTIVATE A NEW CARD
Where a single counter post office encounters a system failure, the post
office will contact the CMS help desk to activate new cards.
[DN: Possible process for activation via help desk to be agréed.]~
3.1.2.4.4 EXCEPTIONS
There are a number of situations where the help desk cannot provide
information to callers. These include:
* the caller fails the verification check
© caller cannot provide NINO, PAN, date of birth, or first line of
address and post code
e the customer is not known to the system
3.1.2.5 MISCELLANEOUS CALLS
Calls received by the help desk which are not card- or PUN-specific will
either be transferred to the appropriate help desk within Pathway, or the
caller advised to contact his local BA office. A percentage of all calls,
including miscellaneous, will be subject to call cause analysis, for MIS
purposes.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 40
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
3.1.2.6 AUDIT AND CONTROLS
For audits and controls see Section 3.1.7, Common CMS & PAS
elements.
3.1.3 TEMPORARY TOKEN PRODUCTION AND ISSUE
3.1.3.1 INTRODUCTION
As part of the BPS, there is a requirement to provide a means whereby a
customer without a valid card can still collect his benefits at the post
office counter.
Pathway will use a Temporary Token, to allow the beneficiary to make a
single encashment at a particular post office. This token will be a ‘one
stop token’, retained and filed locally by the post office for later despatch
to a secure storage location.
This section of the document describes how Pathway propose to manage
the production, distribution, allocation and usage of temporary tokens.
[DN: Confirm the need for Welsh/English tokens.]
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 41
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
3.1.3.2 THE TEMPORARY TOKEN
Pathway will produce books of one stop paper tokens (number of tokens
per book to be defined). Each token within the book will be of the same
size as the encashment receipt as the two items are associated, this will
ease storage and retrieval should this be required at a later date.
Each token will have a unique identification number within each BA
office printed during the production process on the face of the token.
Each token will include pre printed declaration statement.
(DN: Declaration texts to be agreed.]
3.1.3.3 ORDER A BATCH OF TEMPORARY TOKENS.
Each BA Office will maintain a stock of Temporary Tokens. Pathway
will accept orders for stocks of Temporary Tokens from a CAPS
program interface or exceptionally via CAPS personnel contacting the
CMS Help Desk.
Pathway will ensure the delivery of a batch of tokens within seven
working days from the order being placed.
3.1.3.3.1 MAINTAIN REFERENCE DATA
CMS will hold details of each Benefit Office as a ‘customer’ requiring an
on-going supply of temporary tokens. Pathway will establish and
maintain:
e Benefits Agency address ( for delivery of tokens )
© Benefit Office token number range
e Token order status:
« ordered
« produced
e despatched
e received
CMS will maintain the status of the tokens, including:
¢ unassigned .
e assigned
e encashed
° stopped
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE .
C:\PFISCT3A.DOC Page 42
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
e expired
3.1.3.4 PRODUCE AND DESPATCH TEMPORARY TOKENS
Pathway will produce and deliver token orders as received by the CMS
help desk to the appropriate BA office. Each token will have a unique
ID which will be incremented from the I.st number used in the allocated
range for a given BA office.
Token orders will be distributed via the Royal Mail to each BA office.
Tokens not reported at being received in the office within the agreed
period (3 days) will be investigated and invalidated if appropriate.
Pathway will employ alternative carriers in the event of Royal Mail
service disruption, as above.
3.1.3.4.1 BA VIEW POINT
Each BA office will need to maintain a stock of temporary tokens. The
BA office will be responsible for placing orders via CAPS to replenish
stocks.
BA will need to:
¢ maintain a minimum of seven days stock. of temporary tokens
e place request via CAPS for replenishment orders ensuring adequate
stocks exist tO ensure customer service is maintained
e sign for the receipt of a batch of tokens ftom Pathway, ensuring ‘next
book’ carries on from ‘last received’
reconcile the number received with the number ordered
resolve any anomalies via CMS help desk
advise CMS of receipt via CAPS
allocate temporary tokens to customers via CAPS (to PAS)
3.1.3.5 TOKEN ASSIGNMENT
Temporary Tokens will be assigned only by the local BA office to
customers known to CMS. This can occur where payments are
outstanding within PAS but the customer has no card for benefit
encashment (card in production).
3.1.3.5.1 BA VIEW POINT
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 43
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
The allocation of a temporary token to a customer will be carried out by
BA staff in local BA offices. On assignment to a customer, BA will
provide CMS with the following information:
© unique token ID assigned,
© customer’s NINO
e particular post office for encashment
3.1.3.5.2 CUSTOMER VIEW POINT
The customer will be required to: j
e sign the token upon receipt
© encash the payment at the particular post office within seven days of
assignment
e hand in the token on collection of payment(s)
© provide additional identification at the post office counter
3.1.3.6 PAYMENT PROCESSING
Pathway will ensure that the payment or payments associated with the
token are available for collection within 30 minutes of notice of
assignment.
[DN: Confirm that the requirement is 30 minutes, 90 minutes in some
references.]
Pathway will also associate all subsequent payments with the token
-until:
e the token is used,
e token expires,
e token is stopped,
e anew card is activated.
CMS will treat the token as a card issue against the given card holder.
CMS will advise PAS of token assignment as a cardholder amendment so
that outstanding or future payments can be assigned to the token.
A token expiry date will be calculated as date of assignment plus the
value of a system parameter, initial value seven days.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 44
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
3.1.3.7
3.1.3.8
3.1.3.9
PAS will notify CMS when the token is used for encashment purposes.
The temporary token will only be usable for a single encashment at a
nominated post office.
CMS will maintain a token status whilst the token is valid and will place
a token status ‘stopped - used for encashment’ on notification of
encashment.
ISSUE TEMPORARY TOKEN PAYMENT
This process handles emergency authorised payments from CAPS for
customers without a valid card. Valid authorisations are logged and
distributed to the particular post office to await collection and CMS is
notified of issue of the token.
[DN: Emergency payments using a temporary token will need to be
distinguished within the payment authorisa.ion record provided by
CAPS.]
(The payment authorisation will be accessed via the temporary token ID.
Other payments besides the emergency payment will be accessed via the
associated NINO. An emergency payment may be not be present in the
record: in this case the temporary token method is being used to effect
encashment of pre-existing ordinary payments only.) -
A temporary token will be issued only to a beneficiary or appointee. A
customer must have a temporary token as his current form of card and it
must be active and available.
INVALIDATE TOKEN ON EXPIRY
CMS will identify temporary tokens where there has been no
encashment and the expiry date has been reached. The token status will
be updated to ‘stopped - expired’. The token will no longer be valid for
payment encashment.
CANCEL A TOKEN/ BATCH OF TOKENS
CMS will stop a batch of tokens .
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 45
FUJ00119561
FUJ00119561
* Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
3.1.3.9.1 BA VIEW POINT
Authorised BA staff can contact Pathway via the CMS help desk to
cancel token / batch by quoting:
e BA office ID
e token number/range
@ reason for cancellation
3.1.4 PAYMENT AUTHORISATION SERVICE
3.1.4.1 INTRODUCTION
This section describes the services provided by the Payment
Authorisation System (PAS) and how BA and BA Customers and POCL
counter staff will use the service as part of the end to end Benefit
Payment Service (BPS).
PAS is required to be normally available for bulk data transfer to and
from CAS/CAPS for 24 hours a day every day of the year. The on-line
services supported by the help desk will be available to support the BA
and POCL normal business hours (0800 to 1800 Monday-Friday, 0800
to 1300 Saturday, Bank Holidays excepted.)
PAS provides facilities for the management of beneficiaries and
payments authorised for collection by beneficiaries or their
representatives. The key interfaces for PAS ate:
e CAPS Access Service (CAS) to PAS for adding, modifying or
cancelling beneficiary and payment details
e PAS to CAS for notification of payment collection, operational
reporting including exception reporting and management
information
e PAS to POCL Infrastructure Services to distribute payments and
collect encashment details
e PAS to PAS help desk to provide interactive information to Benefits
Agency and post office counter staff
e PAS to the Card Management System (CMS) for ensuring payments
to be collected are available to the appropriate cardholders and their
cards.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 46
Pathway
Ref: PFS/PA/O01
Version: 3.0
Date: 22/5/96
DSS/POCL Functional Specification
3.1.4.2
3.1.4.3
3.1.4.3.1
3.1.4.3.2
OVERVIEW OF THE PAYMENT AUTHORISATION SERVICE
FUJ00119561
FUJ00119561
Beneticiary and
Payment Details Post Office
Counters
BES Dara
Payment Payees
deails
Phone Calls
from: I
Cardholder derails
requests & responses: r=
PAS Help
Desk Card
Management
Service
Figure 3-3: The Payment Authorisation Service
BENEFICIARY PROCESSES
NEW BENEFICIARY
New beneficiaries will have additional validation on:
e beneficiary NINO to ensure the beneficiary is previously unknown or
is flagged ‘end of interest’;
¢ beneficiary nominated post office to ensure a match against post
office reference.
Valid beneficiary advices will result in the addition of the beneficiary to
the beneficiary database. This includes the reactivating of a beneficiary
with a status previously marked as end of iucerest.
(DN: Reinstatement of ‘dormant’ beneficiary to be agreed.]
AMENDMENT TO BENFFICIARY DETAILS
Amendment to beneficiaries will have additional validation on:
Printed:
22/05/96
C:\PFISCT3A.DOC
COMMERCIAL-IN-CONFIDENCE
Page 47
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
3.1.4.3.3
3.1.4.4
e beneficiary NINO to ensure the beneficiary is known and is flagged
‘currently of interest’;
¢ beneficiary nominated post office to ensure a match against post
office reference
[DN: Confirmation needed that amendment to beneficiary will provide
a complete replacement for all data items.]
Valid beneficiary change advices will result in the replacement of
existing beneficiary details by the values from the CAPS record.
Beneficiary data will be copied directly from the CAPS record.
[DN: Discussion and agreement required on the archive treatment of
superseded data.]
The foreign payment details for the beneficiary will not be modified.
Beneficiary amendment details will be applied to any outstanding
authorised payments as well as being applicable to new authorised
payments.
BENEFICIARY NO LONGER ENTITLED TO BENEFIT
A beneficiary no longer entitled to benefit will be validated to ensure he
is. currently a known beneficiary and currently of interest” = ~~~
The beneficiary may have uncollected payments. These can still be
collected or expire as normal.
In the event the beneficiary becomes ‘of interest’ again they will be
deemed a new beneficiary.
Any card assigned to the beneficiary will not be collected as a result of a
notification of end of interest
AMENDMENT TO CARDHOLDER DETAILS
PAS will ensure that any outstanding payments that may be collected by
a cardholder will be aligned with the latest cardholder data. Cardholder
changes which will be applicable for payment collection are:
e change of card Primary Account Number (PAN), this includes the
allocation of a temporary token
© change of card issue number
© change of card expiry date
Printed: 22/05/96 COMMERCIAL.IN-CONFIDENCE
C:\PFISCT3A.DOC Page 48
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
change of cardholder name
change of cardholder nominated office
change of cardholder address iine 1
change of cardholder post code
change of cardholder national sensitivity status
3.1.4.5 ISSUE AUTHORISED PAYMENT
Authorised Payments will have additional validation on:
beneficiary NINO to ensure the beneficiary is known and is flagged
‘currently of interest’
payment ID to ensure no duplication for the authorised payment
the nominated post office indicated is known and is in service
when the beneficiary is also a payee that the beneficiary NINO is a
known, currently of interest cardholder
when the beneficiary is not a payee that .he first payee NINO is a
known, currently of interest cardholder
Additional checks will be carried out:
Other payee NINOs will be validated to ensure they are known,
currently of-interest cardholders. Any mismatch will generate
warning exceptions for reporting via CAS showing that the
authorised payment is accepted (subject to other validation) and the
payee group rejected.
To ensure.at least one payee has a card which can be used to actually
collect the payment. This includes payees with current usable cards,
payees with cards in production and payees with suspended cards.
Failure to meet this criteria will result in an exception reported to
CAPS. The authotised payment is accepted (subject to other.
validation), collection will require a payee to have a card issued
and/or unsuspended. The payment may be cash and/or tokens and
only encashed once.
[DN -The rules for administering signing agents/permanent group agents,
and their agents, are to be agreed.]
3.1.4.6 PENDING PAYMENT STOPS
Valid authorised payments are checked against outstanding payment
stops. Where a matching payment ID is found CAS is notified for
onward routing to CAPS. The advices generated and notified to CAS
are:
Printed: 22/05/96
COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 49
FUJ00119561
FUJ00119561
~ Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
e cancellation of stop payment confirmation
¢ successful stop payment confirmation
The payment will be recorded in PAS with the payment status set to
stopped.
3.1.4.7 PAYABLE AUTHORISED PAYMENTS
PAS will record payable authorised payments and forward the payment
records enriched with payee details to the POCL Infrastructure Services.
3.1.4.8 RAPID PAYMENTS
The difference in the service for normal and rapid payments is in the
timing for delivery of rapid payments. Rapid payments will be received
from CAPS via CAS up to 2200 on the evening before the day they are
encashable. Within PAS rapid payments will have no greater priority
than normal payments encashable on the same day.
[DN: There is inconsistent use of the term “urgent”, to be resolved.]
3.1.4.9 EMERGENCY PAYMENT - ~
Emergency payments vary from a normal issue due to the time allowed
for the payment being available for collection. Emergency payments
will be received from CAPS via CAS on the day they are encashable.
Emergency payments will be available for encashment within 30 minutes
of receipt.
3.1.4.10 CONTINGENCY PAYMENT
As contingency against the loss of CAPS, PAS can automatically generate
payments and provide details of encashments generated as exception
reporting for BA to action.
BA will advise PAS to invoke contingency payment processing. This
includes provision of start value payment, identifiers for generation of
contingency payments and notification of the contingency date for
payment.
The contingency payment will be based upon the last authorised
payment details. A new authorised payment will be created, this will use
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 50
FUJ00119561
FUJ00119561
Pathway . : Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
the next payment predicted amount, cash and/or tokens, as the
encashable amount for the contingency payment subject to the following
checks:
© next payment earliest encashment date will match the contingency
date for payment;
© beneficiary must have currently of interest status;
© payment status of previous payment must be encashed or unpaid.
Cardholders assigned in the authorised payee group for the original
payment will be able to collect the contingency payment. This will be
subject to scrutiny of the individual cardholder/card status.
¢ the cardholder status must be currently of interest.
A contingency payment advice will be passed to CAS (or contingency
alternative) for exception reporting.
PAS will retain contingency payments with Other authorised payments.
Any complementary service functions including stops, enquiries and
further contingency payment generation can be applied.
(DN: The process for both initiating this contingency activity and for
reporting payment, expiry and stops, needs to be agreed.]
3.1.4.11 ENCASHED PAYMENT
3.1.4.11.1. CARD ALERTS ON MONITOR USAGE
Any usage or attempted usage of cards with monitor usage set for them,
will have card alert reporting . This level of report is in addition to any
other reporting generated by encashment of a payment.
3.1.4.11.2 ENCASHMENTS INFRINGEMENTS
Customers attempting to use their card at an office other than their
nominated office will be checked to ensure this is permitted. If the
customer is not allowed to use the office the attempted infringement is
reported to CAPS, via CAS.
¢ attempted collection of 2 payment where that type of payment has a
geographical restriction on collection, i.e. limited to Great Britain or
Northern Ireland
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC . Page SL
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
3.1.4.11.3
3.1.4.11.4
e attempted collection of a payment at an office other than that office
specifically assigned for collection of the individual payment
e attempted collection of any payments for a beneficiary at an office
other than that office specifically assigned to that beneficiary
e attempted collection of any payments for a beneficiary which would
not comply with rules for foreign encashment of payments for a
beneficiary
¢ attempted collection by a casual agent at a foreign office.
Supplementary infringements are also available from PAS:
e where the exclusion of payments results in no authorised payments
being available for collection, an infringement record will be generated
for advising PAS
e where the customer cancels encashment without collecting
ENCASHED PAYMENT REPORTING
An encashment record will be generated each time payments are
collected for an individual beneficiary.
PAS will also provide supplementary validation of the encashment
against the authorised payment instructions. Reconciliation will be based
upon matching payment ID to confirm:
e all payments for this encashment exist and are not stopped, expired
or previously encashed
e the encashment card exists and is active, that is not stopped, expired,
suspended or in production
e the encashment amount is equal to the sum of the individual
authorised payments. The sum includes both money and tokens
Individual reconciliation failures are reported to CAS.
EXPIRED PAYMENT
Where an uncollected payment will expire today and the post office has
been out of action during the previous day the payment expiry date will
be extended by one working day.
(DN: this will be a future date.}
Payments which are not collected by the payment expiry date will be
reported to CAPS, via CAS.
Printed: 22/05/96 .COMMERCIAL-!N-CONFIDENCE
C:\PFISCT3A.DOC Page 52
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
3.1.4.12 STOPPED PAYMENT
This handles stops for authorised payments provided by CAPS.
Responses are generated by CMS as stop payments confirmation
records.
e expired payments, previously stopped payments and payments
already paid are reported to CAS as a failed stop payment
confirmation
e unmatched payment stops are reported to the CAS as an unknown
stop payment confirmation and held in suspense for matching against
new issued authorised payments later in the business day
© unpaid payments are flagged with a payment stop and reported to
CAS as a successful stop payment confirmation
3.1.4.13 ENQUIRY ON PAYMENT DETAILS
This process handles enquiries requiring access to payment information.
Enquiries may originate from a variety of sources: CAPS, PAS Help
Desk, or in the longer term, BA offices.
The enquiry facility is available to handle paymeat and encashment
queries arising between the period when an authorised payment is
provided from CAPS and the subsequent expiry, encashment or stop
confirmation is notified back to CAPS.
¢ unpaid payments are reported to CAPS, via CAS.
e expired payments, previously stopped, payments and payments
already paid are reported to CAS
e unmatched payment stops are reported to CAS.
3.1.4.14 CUSTOMER NOTIFICATION OF CHANGE OF DETAILS
3.1.4.14.1 I NOTIFICATION OF CHANGE OF NOMINATED POST OFFICE
The customer can request that payments and cards be collected at a
post office other than the currently nominated office. This change will
be actioned immediately against Pathway records and forwarded to
CAPS for application to BA records (or denial).
Card Alert Reporting will apply for customer notifications at the
Counter.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 53
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
3.1.4.14.2 I INFRINGEMENTS
This process includes the presentation of a card for which there may be
constraints on usage.
e change of office using a temp-rary token will not be allowed
e change of office by a casual agent will not be allowed.
© change of office when the beneficiary restricted post office indicator
is set will not be allowed. The customer will not be allowed to make
the change and the transaction will be reported to CAS as an
infringement of restricted post office collection
[DN: CAPS. may need to distinguish these from other infringements.]
3.1.4.14.3 VALID CHANGES
Where the customer changes the nominated office a single change
record will be generated. PAS will automatically apply the change of
nominated office to the beneficiary details where a beneficiary NINO
has the same value as the cardholder NINO. Payments will
automatically be assigned to -he new office.
PAS will automatically inform CMS of the associated cardholder change.
CMS will update the cardholder’s nominated office.
3.1.4.14.4 NOTIFICATION OF CHANGE OF ADDRESS
The counter customer will notify BA of a change of address using
modified P80MA procedures at the post office, and not via the Pathway
systems. This may or may not be in conjunction with a change of
nominated office.
CAPS will notify the address change via a personal details change.
[DN: Confirm customer statement request not supported]
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\PFISCT3A.DOC Page 54
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 5/22/96
3.1.5
3.1.5.1
PAYMENT AUTHORISATION SERVICE (PAS) HELP DESK
INTRODUCTION
The Payment Authorisation Service (PAS) receives payment entitlement
and related information from CAPS via CAS.
The PAS help desk, will provide BA/POCL with a single point of contact
for dealing with all enquiries relating to the entitlement, status of
automated benefit payments. The PAS help desk will provide separate
telephone numbers for BA and POCL counter staff. The help desk will
not deal with payment enquiries from BA customers. POCL counter staff
calling the help desk to enquire upon payment entitlements will be asked
to refer their customer to theif local BA office. See Appendix B for a full
list of enquiry types. ‘
As an integral part of the authentication précess for the validation of
callers, BA and POCL staff calling the help desk will be asked to answer
verification question(s). This security measure will ensure that only those
members of staff nominated by the authorities will have access to the
help desk services.
Pathway’s internal access to PAS via the help desk will be strictly -
controlled. Only staff with the appropriate access level will have the
authority to amend the status of payments.
The help desk staff will not be able to alter the amount of entitlement
indicated on PAS.
All status changes will be subject to a complete audit trail.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC . Page 55
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 5/22/96
BA STAFF PAS HELP
DESK
POCL
COUNTER
STAFF
Figure 3-4: Overview diagram of PAS help desk
The PAS help desk will normally be available to take calls, Bank Holidays
excepted:-
Monday to Friday 08C0 - 1800 oo
Saturday 0800 - 1300 . . - =
However, a limited service will be cvailable between the hours of 5 am
and midnight Monday to Saturday to support payment information to
single counter post offices open outside normal working hours.
All calls will be answered to agreed SLA timescales and charged at local
call rate. For contingency purposes the help desk will be split across two
sites.
3.1.5.2 BENEFITS AGENCY CUSTOMER’S VIEWPOINT
The PAS help desk will not deal with calls from BA customers enquiring
on payment entitlements. Enquiries via POCL staff will be referred the
local BA office.
3.1.5.3 BENEFITS AGENCY STAFF VIEWPOINT
Printed: 22/05/96 COMMERCIAL-IN-CGNFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 56
FUJ00119561
FUJO0119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
The PAS help desk will act as a focal point for authorised BA staff to
enquire upon the status of payments held on the PAS. Contact to the
help desk will be via the telephone.
3.1.5.3.1 CALLER VERIFICATION :
To ensure that the caller is an authorised user of the help desk service,
verification question(s) will be asked before any information is disclosed.
In order to access the information held on PAS , BA staff will be
required to provide the beneficiary’s NINO for each customer’s identity
they wish to enquire upon.
Where BA staff wish to place a stop on a payment, the payment ID can
be used to access the payment details.
3.1.5.3.2 CAPS/CAPS ACCESS FACILITY NOT AVAILABLE
If the CAPS/CAS facility is not available for BA staff to make enquiries
on payments or place payment stops, the PAS help desk will take
instructions by telephone from authorised BA staff and take the
necessary action.
[DN: The process for returning confirmations ts to be agreed.]
3.1.5.3.3 PAYMENT STOP
Payment stops can be applied via the help desk. Notification of stop
failures at the counter will be deteczed by PAS and reported to the help
desk, where exception reports will be produced.
3.1.5.3.4 ENQUIRE UPON PAYMENT STATUS
Authorised BA staff can make enquiries on payment status via the PAS
help desk.
3.1.5.3.5 CALLS ON BEHALF OF BA CUSTOMERS
The PAS help desk wi!l not deal with payment entitlement enquiries on
behalf of BA customers.
3.1.5.3.6 EXCEPTIONS
There are a number of situations where the help desk cannot provide
information to callers. These include:-
e the caller fails the authentication check
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 57
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 5/22/96
3.1.5.4
3.1.5.4.1
3.1.5.4.2
3.1.5.4.3
3.1.5.4.4
e caller cannot provide beneficiary NINO
e the customer is not known to PAS
POCL COUNTER CLERK’S VIEWPOINT
The PAS help desk will act as a focal point for authorised POCL counter
staff to enquire upon payment information and request additional
personal information to confirm customers identity, where the Benefit
Encashment Service (BES) is disrupted.
CALLER VFRIFICATION
To ensure that the caller is an authorised user of the help desk service,
verification question(s) will be asked before any information is disclosed.
In order to access the information held on PAS, counter staff will be
asked to provide the customer’s NINO for each payment they wish to
enquire upon.
ENCASH PAYMENT VIA THE HELP DESK
Where a single counter post uffice encounters a system failure the post
office will contact the help desk to encash payments. The help desk will
update PAS, and PAS will update the post office counter when the
system is recovered.
ENCASH FOREIGN PAYMENT VIA THE HELP DESK
The help desk will also authorise foreign encashments for a post office if
its network connection is lost. On confirmation by the post office clerk
that the payment has been made the help desk will cause the appropriate
home post office’s records to be updated, preventing any further
encashments of that payment.
CHANGE NOMINATED POST OFFICE VIA THE HELP DESK
Changes to customers nominated post office can be made via the help
desk, where the system is down at the post office. Prior to making any
changes the help desk will ensure that there are no markers i.e.
restricted post office shown on the customers personal details.
[DN: The requirement and process for this is to be discussed and agréed.]
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 58
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
3.1.5.4.5 EXCEPTIONS
There are a number of situations where the help desk cannot provide
information to callers. These include:-
the caller fails the authentication check
caller cannot provide card details
the NINO is not known to PAS
if payments are unavailable
3.1.5.5 MISCELLANEOUS CALLS
Calls received by the help desk which are not payment specific will be
either transferred to the appropriate help desk within Pathway, or the
caller advised to contact his local BA office. A percentage of all calls,
including miscellaneous ones, will be subject t@ call cause analysis for
MIS reporting. eo
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page S9
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 9/22/96
3.1.6 BPS GENERAL
3.1.6.1 OPERATIONAL STATUS
Operation of all system components of the Benefit Payment System
(BPS) will allow certification in accordance with Police and Criminal
Evidence Act (PACE) and equivalent legislation in other territories.
The operation of and data relating to CMS and PAS will support logical
separation of the two components of the BPS. The individual PAS and
CMS sections identify where data interfaces are required between the
two.
Pathway will maintain the audit trail during all periods of operation
including fallback and recovery. The audit trail will:
¢ record all transaction and data passing across service boundaries and
all major processing actions
e be capable of tracking a DSS business transaction through the services
for which it is responsible
e identify the source or sources of a transaction, its date and time.and
its outcome
e be available for inspection by DSS
© be retained for a period consistent with the requirements of thé
Companies Act
[DN: The application of the Companies Act to this data needs discussion
and agreement.]
3.1.6.2 TECHNICAL SUPPORT
As an integral part of the service components for BPS, Pathway will
provide a technical help desk. This help desk will respond to and
resolve any enquiries raised by BA operational and technical support
staff relating to the interfaces between BPS and DSS systems. Help desk
staff will also raise enquiries with BA staff.
3.1.6.3 VALIDATION OF CAPS DETAIL RECORDS WITHIN CMS/PAS
PAS will validate individual items on the detail records provided by
CAPS. Validation will be according to the semantics of the CAPS to PAS
and CMS Data Interface Specification. Any supplementary validation
for a specific record type is detailed within the CMS and PAS sections of
this document according to the CAPS Interface assignment of the
record.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC . Page 60
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 5/22/96
3.1.6.4
3.1.6.5
Validation failures will usually result in a rejection of the beneficiary
detail record and exception reporting via CAS. The rejection will be
logged within PAS. Where a particular record is not rejected a warning
will be issued as part of exception reporting. Conditions which generate
a warning are described within the sections for each specific record type.
AUDIT AND CONTROL
Access to BPS will be controlled as prescribed by the BPS Security
system. Only authorised users will have access to BPS. All accesses and
changes to the system will be date and time stamped. An audit trail of
changes made to the system will be kept within BPS including:
user ID of user who made the change,
data and time of the change took place,
event record of any enquiry,
record content ‘ before’ and ‘after’ the change.
The above information will be made available.to the authorised staff for
later analysis
Records which are nationally or locally sensitive will be handled in
accordance with the latest version of DSS IT Security standards.
[DN: Confirmation of the use of NSI procedures is required.]
All aspects of CMS and PAS described here will be secure and auditable
and will allow for the production of audit trails for all cards and
collateral material, and changes for cardholders, beneficiaries and
payments throughout their life cycles.
MAINTAIN POST OFFICE REFERENCES
PAS will accept notifications of additions/amendments/deletions for post
offices from POCL Infrastructure Services. For any amendment and
deletion of a Post Office:
e PAS will re-assign any outstanding authorised payments allocated to
that office to the agreed alternative office. PAS will check for
beneficiary use of the office. Where a match is found the beneficiary
nominated office is amended to the new office. PAS will notify CAPS,
via CAS, of change of nominated PO records.
e CMS will check for cardholder use of the office. Where a match is
found the cardholder nominated office is changed to the new office.
CMS will provide an exception for reporting to CAS.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 61
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
3.1.6.6
3.1.6.7
3.1.6.7.1
3.1.6.7.2
3.1.6.7.3
3.1.7
3.1.7.1
3.1.7.1.1
MAINTAIN BENEFIT PAYMENT REFERENCES
PAS will accept additions/amendments/deletions for benefit payment
types, benefit payment offices and regions, benefit payment card types
and benefit payment messages.
DATA HOUSEKEEPING
BENEFICIARIES
Beneficiary details for NINOs designated no longer of interest will be
deleted from PAS after that status has been maintained for 90 calendar
days.
CARDHOLDERS
Cardholder details for NINOs designated no longer of interest will
deleted from CMS after that status has been maintained for 90
consecutive days.
[DN: Discussion and agreement on these periods.]
PAYMENTS/ENCASHMENTS
Payment details for encashed, expired and stopped payments will be
deleted two days after notification to CAPS.
(DN: This can be extended to up to five days, discussion and agreement
required.]
COMMON CMS & PAS ELEMENTS
BENEFITS AGENCY MANAGEMENT INFORMATION
MANAGEMENT INFORMATION (SUMMARIES)
The reports address contract management, audit, accounting and
security and are based upon the Benefits Payment Service MIS
Requirements Catalogue, version 2
Each report is described below and referenced back to the BPS
Requirements Catalogue. In all cases, report details will be delivered by
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC. Page 62
FUJ00119561
FUJO0119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
BPS to CAS which manages the interface with the BA. This service will
offer the flexibility of delivery of report content on a range of media.
[DN: Report formats will be discussed more fully at the next stage and
will include the option of delivery in a format appropriate for processing
by automated processes within the Benefits Agency.]
Management information will be made available to BA at least five
working days before regular Service Review Meetings.
[DN: R743. Report preparation standards need to be agreed for ad hoc
meetings. ]
3.1.7.1.2 CONTRACT MANAGEMENT
3.1.7.1.2.1 REQUIREMENT 1: CARDS ISSUED
An analysis of the number of cards issued per month will be provided.
The count will be broken down per card type to give number issued
__ by reason.
e Card type:
° BA -
e SSA
e WPA
e BA Welsh
e WPA Welsh
e Reason for issue of card
e new card holder
e previous card lost
¢ previous card stolen
¢ previous card damaged
e previous card expiring
The analysis will be provided by post office, POCL Region and by BA
area.
3.1.7.1.2.2 I REQUIREMENT 2: TYPES OF CALLS TO THE CMS HELP DESK
Pathway’s call management will enable the classification of calls to the
CMS Help Desk. Monthly and annual analysis of the number of calls
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC. Page 63
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version:: 3.0
Date: 5/22/96
3.1.7.1.2.3
3.1.7.1.2.4
3.1.7.1.25
3.1.7.1.2.6
3.1.7.1.2.7
3.1.7.1.2.8
per type will be produced. The help desk has catalogued thc type of
calls expected from the three (or more) classes of customer: Post Office
staff, Benefits Agency staff, customers and other.
REQUIREMENT 3: REGIONAL ANALYSIS OF TYPES OF CALLS TO THE
CMS HELP DESK
The call analysis described above will also be produced by POCL region
and BA area to enable detection of regional variations and will be
further subdivided by customer group. This analysis will be based upon
data gathered on the CMS/PAS Help Desk Automated Call Distribution
(ACD) facility.
[The precise definition of the basis for assigning a region to a call needs to
be discussed and agreed.]
REQUIREMENT 4: CALLS LOST OR ABANDONED
Pathway’s call management will enable the counting of lost and
abandoned calls. The number of such calls will be reported monthly
and annually.
REQUIREMENT 5: LENGTH OF CALLS. - . _
The length of each call to the CMS help desk will be measured for each
customer group (as defined in requirement 2 above). The average length
of call per customer group will be derived and reported monthly and
annually.
REQUIREMENT 6: QUALITY OF SERVICE OFFERED TO CALLERS
Supervision of the CMS help desk will include assessment of the level of
customer satisfaction ona sample of calls. This analysis will be input to
Pathway’s own appraisal of conduct of the help desk and forwarded
quarterly to BA.
REQUIREMENT 7: CARDS AND PUNs LOST IN TRANSIT
The CMS help desk will keep a record of cards and PUNs lost in transit.
This will be forwarded to the BA monthly.
REQUIREMENT 8: TRANSACTIONS AUTHORISED
Printed: 22/05/96 COMMERCIAL-N-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 64
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
An analysis of the number and value of transactions authorised per post
office will be produced weekly, monthly and annually to highlight
trends and to enable validation against data held within the bounds of
the BA. The analysis will be subdivided to indicate the number value of
payments to each class of payee - e.g. beneficiary, casual agent,
permanent agent, appointee and alternative payee.
3.1.7.1.2.9 I REQUIREMENT 9: FOREIGN ENCASHMENTS
An analysis of the number and value of foreign encashments will be
provided weekly, monthly and annually to enable review of trends. The
various classes of payee will be separately identified on this analysis (as
per requirement 8)
3.1.7.1.2.10 REQUIREMENT 10: PHANTOM WITHDRAWALS
As a by-product of investigation of customer repudiations, a monthly
analysis of alleged and actual phantom withdrawals will be delivered to
enable trend analysis and assist in fraud detection. Fuller details of each
instance will be available.
3.1.7.1.2.11. REQUIREMENT 11: PAYMENTS MADE UNDER FALLBACK
PROCEDURES
The number and value of payments made per pest office under fallback
procedures will be reported weekly, monthly and annually so as to
enable the identification of areas experiencing difficulty.
3.1.7.1.2.12 REQUIREMENT 12: RECORD OF CARD TRANSACTIONS
A count of card-based payment encashments will be provided weekly,
mouthly, quarterly and annually to support accounting and validation
activity.
3.1.7.1.2.13 REQUIREMENT 13: TEMPORARY TOKENS ISSUED
The number of temporary tokens issued per month will be reported and
will be summarised annually. Subject to establishing a mechanism for
BA advising Pathway of reason for issue of the temporary token, the
analysis will be provided by reason.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 65
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
3.1.7.1.2.14
3.1.7.1.2.15
3.1.7.1.2.16
3.1.7.1.3
3.1.7.1.3.1
[DN: Confirmation is sought that this refers to issue to the customer not
the BA office.]
REQUIREMENT 14: CARDS ACTIVATED
An analysis of cards activated eawh week will be provided weekly and
rolled up to provide monthly, quarterly and annual activations.
REQUIREMENT 15. CARD IMPOUNDED AND INVALIDATED
There are a number of situations in which a card is impounded or its use
invalidated. An analysis of such actions will be provided by reason and
delivered weekly and monthly. This will be provided by post office
within post code within town and will enable the identification of
problem districts and the nature of the problem to potentially prompt
corrective action. This analysis will also be provided for temporary
tokens.
[DN: post code at the lowest level is typically a block of 30 dwellings.
Further discussion is required as to the use of the post code for grouping.]
REQUIREMENT 16: CARDS PER POST OFFICE
The number of active cards per nominated post office will be reported
weekly, monthly and annually to enable monitoring of any unusual
trends.
AUDIT
REQUIREMENTS 17-20: RANDOM SELECTION OF DATA AND BESPOKE
ANALYSES
A support team within Pathway will use standard ORACLE7 tools to
interrogate the current PAS and CMS databases and produce reports on
an ad hoc basis. These tools offer considerable flexibility in retrieval of
data and presentation of results. Each instance will be subject to
consideration of impact upon operation.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 66
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
3.1.7.1.4 ACCOUNTING
3.1.7.1.4.1 REQUIREMENT 21: PERIOD-END SUMMARY OF OUTSTANDING
PAYMENTS
By consideration of newly authorised payments, encashments, expiring
payments and any adjustments, a summary of payments outstanding will
be produced at the end of each week and month for use in
reconciliation.
3.1.7.1.4.2 I REQUIREMENT 22: MISMATCHES
The Pathway solution offers a secure delivery mechanism for ensuring
the authorised money is paid to the correct person and at a legitimate
location. Some deviations are detectable automatically when, for
instance, the data passed back from counters:is compared with centrally
held data. °
Other deviations will only be found by detailed investigation as part of
query resolution. Where a difference between intended and actual event
is found, the mismatches will be reported daily and summarised by type
to enable investigation and correction.
3.1.7.1.4.3 REQUIREMENT 23: UNCASHED TRANSACTIONS
A summary of uncashéd payments will be reported daily as input to
reconciliation processes.
3.1.7.1.4.4 REQUIREMENT 24: ATTEMPTED CARD AUTHORISATIONS
As input to the review of transaction times at the post office counter, an
analysis of number of card swipes attempted in card authentication will
be produced weekly and will present the data as a simmary across all
post offices. In the évent that less than 95% of cards are read on a single
swipe at a given post office, the analysis will be provided for that given
office.
3.1.7.1.5 SECURITY
3.1.7.1.5.1 REQUIREMENT 25. IRREGULAR ENCASHMENTS
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC . Page 67
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
Instances of irregular behaviour wil! be reported weekly. This will
encompass reporting of :
number of means tested benefits uncashed after four weeks
number of non means tested benefits uncashed after six weeks
change of nominated office without change of address
within six weeks
excessive use of casual agents
attempted encashment of a stopped payment
eoeeee
[DN: Clarification of what constitutes attempted access to a stopped
payment is required.]
© payments with an associated loss report
© presentation of non-genuine cards or apparently duplicated card
e keyed transaction outside service hours
[DN: Clarification of which transactions may not be keyed out of hours
is required.]
e keyed transactions or telephone authorisations, by clerk and outlet,
where no report of system outage is reported.
© transactions from an office marked as temporarily out of commission
3.1.7.1.5.2 I REQUIREMENT 26: NUMBER OF FALSE ACCEPTANCES AND
REJECTIONS
Investigation into queried payments may result in marking of the
payment as a false acceptance of an invalid card or false rejection of a
valid card. A report of the number of such instances will be provided
periodically to enable assessment of the extent to which customers are
having problems obtaining their correct entitlement.
3.1.7.1.5.3. REQUIREMENT 27: CARD AUTHENTICATION FAILURES
The number of instances of erroneous authentication of a counterfeit
card and failure to authenticate a valid card will also be reported weekly
to enable monitoring of effectiveness of security measures.
3.1.7.1.5.4 © REQUIREMENT 28: INTERNAL FRAUD INCIDENTS
Printed: 22/05/96 COMMERCIAL-iN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 68
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
3.1.7.1.6
3.1.8
3.1.8.1
3.1.8.2
The number of incidents of internal fraud within Pathway’s domain will
be reported monthly by the Fraud Management Team, as input to the
assessment of system security.
OTHER MANAGEMENT INFORMATION
The above reflects the catalogued management information needs. A
considerable number of measures of performance against Service Level
Agreement have also been defined. by Pathway for use in measuring the
attainment of Pathway. in servicing the Contracting Parties and also the
attainment of Pathway’s suppliers with regard to service provision.
These measures are relevant to the establishing of under performance or
over performance and to establishing the level of penalties or rewards.
It is anticipated that many of these measures will also be visible to the
Contracting Parties and therefore could be considered at a later level of
specification as an extension to the management information catalogued
above.
CAPS ACCESS SYSTEM ( CAS )
INTRODUCTION
The CAPS Access Service (CAS) haridles the exchange of data between
Pathway and the Benefits Agency’s CAPS. It is envisaged. that this
exchange will initially be at file level but recognised that the exchange
mechanism may evolve under change control to offer a messaging
capability. CAS will be available 24 hours a day, every day of the year,
subject to agreed service maintenance and availability of the common
CAPS platform.
DATA DELIVERY
The delivery of data from CAPS to Pathway will be managed by
introduction of a file transfer interface sited at the boundary of each
CAPS site and associated routing and encryption software. This interface
will ensure that the file is delivered across the link to the appropriate
locations securely. CAS also provides the decryption and file transfer
software at the receiving Pathway site.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 69
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 5/22/96
3.1.8.3
3.1.8.4
The scope of CAS encompasses the file transfer from the CAPS domain,
management of the inter-site communication and the file transfer into
the receiving Pathway system.
The delivery of data from Pathway to CAPS will exploit the same
infrastructure.
MIS REPORTING
The CAS supports the delivery of CMS/PAS data such as exception
reports and ii:ariagement information. Where there is a defined interface
to CAPS, CAS will pass the data forward.
In the event there is no defined interface to CAPS, CAS will deliver to
BA on whatever media is determined and agreed. Where the interface
to CAPS or other BA user evolves, this will be managed by CAS without
impact upon CMS and PAS.
[DN: Contingency reporting routes to be discussed and agreed.]
DATA EXCHANGE
The key exchanges of data will be between CAS and the Card and
Payment Authorisation Services (CMS/PAS). The architecture will ensure
that data forwarded to Pathway is within the Pathway domain before it
leaves the BA site and that data forwarded to BA is on the BA site before
BA need to take ownership. In other words, Pathway is accountable for
the transfer into the inter-site communications network and the actual
movement across the inter-site network.
CAS will act as a buffer between CAPS and PAS/CMS and will address
data formatting so that each of the systems receives or despatches data
in the optimum format. The positioning of CAS between the application
systems also offers the opportunity to protect the application systems
from unnecessary change by protecting defined interfaces wherever
practical.
To ensure early detection of data integrity failures, CAS will perform
some validation of files ex CAPS within the bounds of the BA. This
validation will encompass :
e presence of a recognised file header defining type of data to follow
e file control data such as date/time is valid
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 70
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3:0
Date: 5/22/96
© additional file control, such as sequence number, is as expected (next
in sequence)
© content limited to records of the type(s) associated with the given
header
e where structured record groups are defined, valid group structure is
presented as per the agreed CAPS interface definition
e presence of a file trailer
e control totals on file trailer are consistent with file content
3.1.8.5 DATA VALIDATION
CAS will not perform any validation which requires access to standing
data within the interfacing applications, as this is more properly serviced
by the supplying and receiving applications.
3.1.8.6 SYSTEM INTERFACE
CAS will service an interface to and from CAPS for all the file types for
which a CAPS interface is defined in the CAPS to PAS/CMS Data
Interface Definitions document ( version 5, 22 January 1996 ). Namely:
File From To File type
Authorised payments CAPS _ PAS. 001_
Stop payments CAPS PAS 002
Stop payments confirmation — PAS CAPS 003
Payments expiry PAS CAPS 004
Payments encashment PAS CAPS 005
Card alert PAS. CAPS 006
Restricted PO infringement PAS CAPS 007
Payments enquiry CAPS PAS 008
Payments enquiry response PAS CAPS 009
Change of nominated PO PAS CAPS 010
Customer statement request — PAS CAPS 011
Customer details CAPS PAS 012
End of customer interest CAPS PAS 013
Customer details CAPS CMS 014
End of customer interest CAPS CMS 01s
3.1.8.6.1 EXCEPTIONALLY
File From To File type
Cancel stop payment PAS CAPS 050
Printed: 22/05/96
C:\FINALPRN\PFISCT3B.DOC.
COMMERCIAL-IN-CONFIDENCE
Page 71
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 5/22/96
confirmation
Cancel payment expiry PAS CAPS 051
Cancel payment encashment PAS CAPS 052
[DN: Status of change requests shown in interface specification to be
resolved.]
Confirmation of acceptance of a file ex CAPS, or notification of
validation failure on application of the above checks, will be issued to
CAPS.
3.1.8.7 CMS & PAS INTERFACES
The CMS and PAS application data is held in ORACLE7 relational
databases. To facilitate loading of data ex CAPS into the database
tables, CAS will remove header and trailer information and will deliver
the data records into a directory designated for use as a repository for
the given interface.
The take on of data records into the CMS/PAS databases is based upon
use of standard utilities which require parameters defining operational
characteristics. A limit of 500,U00 records is set on any given data
record load execution.
In instances where there are defined groups of records (authorised
payment instruction with an associated payee list and/or message, for
example), CAS ensures that all records pertaining to.a given payment are
put in the same file.
Similarly, on the return interface from CMS/PAS to CAPS, CAS will
extract information out of designated database tables and will add
header and trailer records containing the appropriate control
information and to satisfy the interface definition.
3.1.9 PAS RECONCILIATION REQUIREMENTS
The formal requirements in relation to PAS comprise:
e reconciliation at the individual payment authorisation level of the
value as received from CAPS and the value of encashments as notified
by BES via TMS
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 72
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
3.1.9.1
3.1.9,.1.1
e reconciliation at the individual payment authorisation level of
encashments received from BES via TMS and the value as notified to
BES via TMS
© provision of the Common Basis of Settlement as between BA, POCL
(and Pathway) I
Reconciliation of value includes tokens by type as well as of monetary
amounts.
Clearly if the same datasets are used to represent the data received from
CAPS and that notified to BES, then the solution to the first two
requirements can be merged into one.
The role of BES is described in. Section 4.
PAS-RELATED RECONCILIATION
The fundamental reconciliation task is the end to end checking of
payment authorisations. This canbe seen as reconciliation between the
enriched payment authorisations sent to BES via TMS and the
encashment and stop notifications and expiry confirmations received
from BES via TMS, having relied on the logical correspondence between
the raw authorisations and the enriched ones.
TIMING, LEGISLATIVE AND REPORTING CONSTRAINTS
As a matter of record, at the time of preparing this level of specification,
the formal requirement is for encashments to be notified by 0400 on the
day following encashment and for expiries to be confirmed by 0300 on
the second day following expiry (Schedule B3, Section 2.1.4, as amended
by the Invitation to Retender (ITR) subject to service level agreements).
A payment authorisation, strictly speaking, becomes effective at 0000-on .
its first day and expires at 2400 on its last day.
At present there are no post offices specified to be open between 0000
and 0500 and only three open after 2200 and before 0600.
Nevertheless, if opening hours were extended, or indeed if a late opening
post office remained open for a few minutes after midnight, such a
payment would be legally encashable in precise accordance with its
validity.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 73
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
3.1.9.1.2 ENCASHMENT AND EXPIRY REPORTING
These requirement and constraints taken together mean that encashment
processing cannot be undertaken with finality until just after midnight,
while systems have to be capable of reporting an encashment at 2400 to
CAPS within four hours.
Expiries have to be confirmed curing the payment’s home office on line
day following the midnight of expiry. Special “day of grace” processing
will allow controlled late payment where an office has been down during
a payment’s last day of validity. (The precise definition of such i
downtime will defined at a later level'of specification.)
It is assumed that encashment notifications and expiry confirmations will
be trickle-fed from BES and TMS back to PAS during the on-line day and
that they will be fed back to CAPS in files containing no more than
500,000 entries. This convention will limit nugatory processing in the
event of file and record validation exceptions.
3.1.9.1.3 EXCEPTIONAL LATE REPORTING
As described, PAS may receive encashment notifications for immediate
reporting right up to midnigint (and a few seconds after). However, it is
possible that an encashment notification may be prevented from reaching
PAS on the day of encashment because BES was not available, for
whatever reason: equipment or telecommunications outage, staff dispute
and so on. In this case the encashment notification will reach PAS during
the next or subsequent day.
A payment authorisation expires at midnight on its last day of validity.
The fact that the nominated offices of the possible payees closed earlier
that evening does not mean that the authorisation can be deemed to have
expired at those earlier times. A payee could collect by way of a foreign
encashment right up to midnight. PAS will therefore normally receive
expiry confirmations during the on-line day following that of expiry.
However, there is a situation in which such normal expiry confirmations
will not be made; if BES was not available, again for whatever reason:
equipment or telecommunications outage, staff dispute and so on, a
beneficiary may not have been able to collect a payment on its last day of
validity. In this case BES will provide for, and if possible notify PAS of, a
one-day extension of the expiry date, and the payment will be permitted
on the next working day (day of grace encashment), with either expiry or
encashment being reported subsequently.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 74
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
3.1.9.1.4
3.1.9.1.5
3.1.9.1.6
PAYMENT STOPS
PAS and BES will handle payment authorisation stops in support of
accurate reconciliation. (A stopped payment authorisation is sometimes
referred to as cancelled, invalidated or voided.) There are two classes of
stop specified: an immediate stop, received during the DSS on-line day;
and a non-immediate stop received as part of the “next working day”
transactions. On receipt of a stop notification PAS will establish if the
payment has been encashed by reference to its own tables then, if
necessary, by reference to TMS and by extension to BES. If the payment
has been encashed then the definitive encashment notification will be
returned at that point if not already returned. If the payment has not
been encashed then TMS and BES will in effect mark the payment as
stopped and CAPS will be notified definitively of the successful stop at
that point. The payment authorisation and stop status will be retained
for reconciliation and settlement reporting.
SCOPE OF RECONCILIATION
Thus PAS will take account of:
e ordinary encashment notifications executed up to midnight and
notified up to midnight (or very shortly after)
e ordinary encashment notifications executed correctly after midnight
(invalid ones attempted after midnight will be prevented by BES) for
reporting by 0400 on the following day in respect of the calendar day
in which they occurred
validity date extensions for day of grace situations
day of grace encashments
expiries both ordinary and for day of grace situations
stopped payments
Note that suspension of a payment suthorisation is reversible, so it is
possible that a suspended payment may be later stopped and reported as
above, or may expire in the suspended state.'
TREATMENT OF PATHWAY ADJUSTMENTS
The formal requirement includes the reporting of differences between
the authorisations and the encashments caused by Pathway’s adjustments
“to resolve errors or due to maintenance activities”. None is defined at
1
Payment suspensions may not be a formal requirement, but are included at this level of
specification.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 75
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 5/22/96
3.1.9.2
this time, except for the day of grace process described above. However,
a clear distinction will be made in, data between a payment authorisation
that has been raised by CAPS in the normal way and one that has been
manufactured by Pathway according to the requirement to provide back-
up to CAPS unavailability (R797, 963).
The means by which the results of this reconciliation process is conveyed
is not specified. It is assumed that it will be included in the Common
Basis of Settlement Report, q.v.
THE COMMON BASIS OF SETTLEMENT
The purpose of the Common Basis of Settlement (CBOS) is to facilitate
financial settlement between BA and POCL and in turn between BA,
POCL and Pathway.
The principle is to form a daily CBOS report using the results of the
CAPS-to-BES reconciliation with additional information for stopped
payments.
The periods of time for which reconciliation is performed are specified as
calendar days, measured from 0000 to 2400.
There will be up to’seven such reports a week: there are currently some
115 post offices open on Sundays and Bank Holidays, and this number
will increase to 200 in the near term.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 76
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
Meeting
‘authorisations ne
CAPS Balances
Encaitments I
Expines
O _——__——_ ™sS
I aps Ba Encoders TF epicoion
L Pe Local Office
‘Jourat
_ I Transactions
The Common Basis ! Ses'ement
Figure 3-5: The Common Basis of Settlement
3.1.9.2.1 REQUIRED OUTPUTS
The required outputs are daily files of:
e matched authorisations
© reconciliation exceptions
e unencashed balances
It is intended that a primary financial settlement be made on the basis of
agreement by BA and POCL to the matched authorisations element of
the Pathway CBOS, and that all parties can then accrue the debits and
credits.
It is further intended that a secondary and final financial settlement be
‘made on the basis of the reconciliation exceptions when these are
resolved by a tripartite meeting of the parties. This secondary settlement
will produce its own audit trail outside of the automated system, that is
there will be no retrospective adjustment to the TMS record.
Over time, as reconciliation exceptions are better understood, benign
ones can be absorbed into the normal operating methods and taken as
part of the primary financial settlement.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC . Page 77
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 5/22/96
Note that a stop or payment enquiry from CAPS for which PAS cannot
find a matching payment authorisation is handled separately from the
reconciliation process. In particular where a stop is in respect of a
payment authorisation not yet received from CAPS, PAS will hold it ina
state pending réceipt of the authorisation which will then lead to a
successful stop originated at the PAS level.
3.1.9.2.2 MATCHED AUTHORISATIONS
This output will be the explicit matching of a payment authorisation that
has been paid, stopped or has expired with the evidence of payment, stop
or expiry.
For each payment authorisation that was, in respect of the immediately
preceding 0000-2400 period:
© notified to CAPS as encashed (including those definitively reported as
having been encashed on stop request)
© notified to CAPS as stopped successfully
© confirmed to CAPS as having expired
a status to that effect, together with:
e the original payment autl.urisation’, plus, as applicable:
© acopy of the encashment notification record
© acopy of the stop notification and associated definitive encashment
notification (for unsuccessful stop requests where thé encashment
was notified with the stop response)
© a copy of the stop notification and stop success notification (for
successful stop requests)
e acopy of the expiry confirmation
3.1.9.2.3 RECONCILIATION EXCEPTIONS
In the process of matching encashments, expiries and stops against
payment authorisations PAS will discover exceptions. Although in ideal
circumstances there should be no such exceptions, in practice there will
be, and each will require individual explanation and resolution both in
terms of system behaviour and financial responsibility.
? This is expected to be the denormalised version with rolled up token and message
records
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC. Page 78
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 5/22/96
Certain classes of reconciliation exception will be anticipated and will be
so categorised:
e Salient data check. The salient data within payment authorisations
should be checked for correspondence with that in the encashment or
stop notification, or expiry confirmation’. Elements of the NINO,
nominated post office, payment date, expiry date and of course value
of cash and tokens will be checked. Matched records for which any
salient data differs will indicate a data corruption, program fault or
fraud. Records whose paid amount differs from the authorised
amount will be a reconciliation failure since in all circumstances
(defined thus far) all payment authorisations must be paid in full or
not at all’, Records indicating late paymenc by reason of day of grace
procedures will be so marked for visibility. Records indicating early
or other late payment will indicate data corruption or fault in either
BES, TMS or PAS, most probably initially a fault in BES. Day of grace
encashments should be shown separately as these are predictably
benign exceptions.
e An unmatched inbound record from BES/TMS (encashment, expiry)
will indicate:
e (encashment) an erroneous or fraudulent injection from the TMS
side (that is paid without authorisation from CAPS) or a double
payment or failure in PAS, all requiring immediate investigation. A
double payment is possible if the policy adopted on foreign
encashment authorisations is such that a payment is made on the
basis of the TMS record when the nominated office is down and a
two way telephone authorisation is not undertaken. However, only
a single, that is one-off, double payment is possible and the
beneficiary’s benefits will be rescheduled to compensate
e (expiry) either a failure in PAS or in TMS or BES requiring
immediate investigation
e An unmatched resident PAS record awaiting payment or expiry
notification after such a notification has become fundamentally
* Where a day of grace extension is in operation neither an encashment notification or
expiry confirmation will have been received from BES/TMS. The payment authorisation
will be held by PAS possibly marked as day of grace extended.
* There has been discussion of payment of a predefined amount in the event of collapse
of the public infrastructure. If implemented this would be against a payment
authorisation whose description from BES would indicate such a payment and PAS
would carry the value as personal data. This extension is not defined at this level of
specification. Note also that where the £1000 maximum rule or Post Office cash limit
applies whole payment authorisations are still paid.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 79
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
3.1.9.2.4
overdue, that is overdue even if a day of grace has been n applied,
would represent:
© an enduring PAS error indicating a duplicated payment
authorisation within PAS
© an “orphaned” PAS record. Orphaned records could occur if a post
office had been put out of action by some event and had not yet
been either brought back into service or officially closed down. In
the case of such a dormant period that is rectified by restart of the
office, any blocked payment notifications, expiry confirmations or
successful stops that did not make it to TMS before the event will
then clear down the orphaned records. If the office is eventually
closed down then the closedown process will be required to notify
such valedictory notifications or confirmations on behalf of the now
defunct office. Alternatively, orphaned records could occur if TMS
had misdirected payment authorisations, payment notifications,
expiry confirmations or successful stops.
It is proposed therefore that such unmatched records are retained on
the reconciliations exception report for visibility and investigation.
UNENCASHED BALANCES
The thrust of this requirement is to supply to BA, by Agency code (NI
Pension, War Pension, Child Benefit, Income Support...), volume and
value data for benefit authorisations that are available for encashment
but which have not yet been encashed in order that track can be kept of
the contingent liability. The data will also be of value to POCL for
contingency cash planning and to Pathway for understanding periodic
variations in resource utilisations.
Care will needed in handling certain classes of work in progress and in
accumulating values within the right torals.
The requirement is to show the effect of encashments, expiries and stops,
and exceptional items.
In the following description the assumption is that this processing takes
place at about 0430 in respect of an unencashed balance as at the
preceding 0000.
The unencashed balance will automatically take account of regular
payments which will have been received by 0800 two days previously,
“next day” payments which will have been received by 2200 the previous
day and urgent payments which will have been received by the close of
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 80
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
the last DSS on-line day (0800-1800 Monday to Saturday inclusive
excluding Bank Holidays, Schedule A1).
e Volume and value of payments brought forward not having been
notified to CAPS as encashed, stopped or expired as at 0000.
This will be equal to the corresponding volume and value of payments
brought forward a day earlier:
e PLUS new payment authorisations notified during the previous day
for immediate validity
e LESS expiries confirmed in respect of the previous day
¢ LESS encashments notified in respect of che previous day
¢ LESS immediate stops successfully applied during the previous DSS
on-line day (up to 1800) (including stops that were held in suspense
for payment authorisations awaited and which were notified for
immediate validity)
e LESS any new stops successfully applied during the batch day (up to
2200) (including stops that were held in suspense for payment
authorisations awaited and which were notified for immediate
validity)
e PLUS new payment authorisations which became valid at the 0000
just passed
These control totals will be verified by column addition. During the
column addition process volume aiid value totals will be accumulated for
payments which have not yet been notified as paid, expired or stopped,
that is are still live within PAS, but which had nominally expired. at 0000
one day earlier. These will represent potential day of grace situations
and unmatched resident records. The nominal expiry date will be readily
variable to two or more days earlier: experience may indicate that late
expiry confirmations, especially during periods of industrial dispute,
should be filtered to manageable levels.
Payment authorisations which become valid on subsequent days will
need to be added into counters for future reference. It is uiilikely that
payment authorisations will be notified more than seven days in advance.
Stops which apply to payment authorisations which are not yet valid will
need to cause their removal! from such counts.
Counters will be maintained for volume and value, and within value
distinguishing between money and types of token.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 8:
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
[DN The accuracy of these methods is believed to be limited only by late
notifications generally and specifically late notifications of the nominally
overdue.]
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 82
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
3.1.10 CMS RECONCILIATION
The formal requirements are to reconcile the card and temporary token
actions against instructions received from BA, recognising that this is
solution-dependent and, in the Pathway solution, involves POCL as a
subcontractor handling card management at the counter.
The near term steady state relationships differ somewhat from those of
PAS: in the case of temporary tokens the primary BA input is not from
CAPS but from the BA offices via the CMS Help Desk.
The CMS card actions are specified in Section I of the BPS functional
specification, Section 2 of the BES functional specification and a
Memorandum of Understanding from Post Office Counters concerning
card receipt and issue. In addition the BPS MIS lists a number of reports
in this area, although not the specific ones detailed below.
3.1.10.1 CMS-RELATED RECONCILIATION
The purpose of this reconciliation is for the parties to be assured that:
e for every customer for whom a card is required a suitable one is
available or in course of preparation for the purpose of payment
encashments, and contrariwise, that for every customer for whom
access to a card is explicitly not required that none is available
e for every BA office order for temporary tokens one is available or in
course of preparation
Some of the specifications referenced and certain responses to
requirements anticipate more operations being required on cards and
temporary tokens than is explicit in others. For example the SID does
not include card suspension or card stop at the behest of the DSS. This
level of specification includes such functions even though they may not
be formally required at this time.
3.1.10.1.1 CARD-RELATED RECONCILIATIONS
At the time of preparing this level of specification there are only two
programmatic transactions initiated by CAPS:
e new or revised personal details notification
e end of interest
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 83
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 5/22/96
For the purposes of reconciliation these act broadly.as a simple on/off
switch. Revised personal details may, or may not, require the card to
replaced. While a card is in course of such replacement the current card
remains available.
The process of reconciliation therefore reduces to keeping a track at
CMS which reflects the various statuses which a card can have. These
are shown in the table below. The full range of statuses which should be
provided for is given. Changes to requirements in this-area can be
anticipated.
Statuses of suspended or non-suspended cards
Inactive Uncollected I Yet to be activated, in production, transit,
or at post office
Lost Did not artive at post office by due time
Stolen Stolen from post office
Damaged Could not be activated
Returned/ Was not activated by due date and was
disabled hole punched and returned
Active In use Activated, the normal state
Subject to alert monitoring
Stopped _I Reported lost (or found)
~ Reported stolen (or impounded)
Reported damaged
Customer denied use by DSS .
Dormant Notified no further interest
Expired Past expiry date
Cancelled Dormant card not replaced when
otherwise due®
The requirement does not specify how reconciliation reports.are to be
communicated. It is therefore assumed that a report should be produced
monthly covering:
© those specific customers for whom a card is required and for whom no
card is available or in preparation
° [DN: During stream meetings a scheme was worked out whereby a card notified as
being of no further interest would not take any further part in payments unless a
renewed personal details transaction was received, when it would be revived. If it expired
before such revival it would be cancelled on expiry... This allowed people to move in and
out of benefit without card replacement. The SID, however, requires that a card be
cancelled on no further interest.]
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 84
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
those specific customers for whom an end of interest is shown as
having been received and not superseded and for whom the card
status is not invalidated. This should be an empty report provided it
is taken immediately after a card/PUN production order sequence.
© counts of customer by card status
3.1.10.1.2. TEMPORARY TOKEN-RELATED RECONCILIATIONS
During the near term steady state BA offices will order temporary tokens
to replenish their stocks by calls upon the CMS Help Desk who will
update a temporary tokens order file. CMS will scan the order file and
produce an order on the temporary token supplier for the numbers
requested and the destination addresses, numbering the temporary
tokens in each individual order incrementing from the last number used
in the allocated range. It is not expected that the BA office will ring up
to say they have arrived so reliance on paper methods of recording
delivery and calls from the CMS help desk to establish arrival will be
required.
In the medium term such orders are expected to be made via a CAPS
application available to BA offices and at that time the application should
also facilitate the confirmation of arrival.
The process of reconciliation therefore is to show that there is a
correspondence of replenishment orders with orders placed on -
production.
Statuses of suspended or non-suspended temporary tokens
Inactive Unissued Yet to be issued by benefit office, in
production, transit, or at benefit office
Lost Did not arrive at benefit office by due time
Stolen Stolen from benefit office
Damaged Could not be issued
Active In use Activared, the normal state
Stopped Reported lost (or found)
Reported stolen (or impounded)
Reported damaged
Customer denied use by DSS
Shot Used temporary token
Expired Past expiry date (issue date + seven days)
The requirement does not specify how reconciliation reports are to be
communicated. It is therefore assumed that a report should be produced
monthly covering:
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 85
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: — 3.0
Date: 5/22/96
e those specific offices for which an order has been received but for
which no order has been placed on the temporary token producer.
This should be an empty report.
e for each benefit office, counts of temporary token by status.
3.1.11 DSS CONTINGENCY SERVICES
To be added following Pathway DSS consultations.
3.1.12 RELEVANT OPTIONAL DSS SERVICES
To be added following Pathway/DSS consultations.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3B.DOC Page 86
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: $/22196
3.2 DSS SERVICE INFRASTRUCTURE
This section is provided to give a context to services’ operation.
Figure 3-6 provides an overview of the DSS Service Infrastructure in each
of the two Pathway datacentres.
The Service Infrastructure will be configured with sufficient capacity to
recover from a failure in CAPS of a maximum duration to be agreed.
[DN: discussion and agreement on the handling of potential CAPS failures
~ _ is required]
Router I
Ethernet
SE70
Megastream
connection ;
to CAPS FDDI
TMS
Figure 3-6: DSS Service Infrastructure hardware and communications
3.2.1 HARDWARE
The heart of the CMS/PAS systems will be a Sequent SE70
multiprocessor machine.
All operational files will be mirrored across independent controllers.
The configuration includes a number of Spectralogic tape subsytems.
These are used prismarily to hold database archives. The number of cape
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3C.DOC Page 87
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 5/22/96
3.2.2
3.2.3
sub-systems to be coiifigured will be determined following agreement on
archiving and retention periods.
[DN: Agreements required cn archiving and retention periods.]
Each CMS and PAS help desk position is based around a PC that is
connected to the LAN. The connection to the Sequent processor will be
on the same logical LAN.
SOFTWARE
The Sequent operating system will be Dynix. This is an implementation
of UNIX developed by Sequent to exploit their multiprocessor
architecture.
The database will be implemented using ORACLE version 7.3. Most of
the application code will interface with the Oracle database. Normally
code will be written in Pro*C which is Oracle’s extension to the standard
“‘C’ language to enable the support of SQL.
The transfers of data from CAPS will be received using File Transfer
Facility (FTF). This is an ICL file transfer protocol implemented within
the Sonnet suite that supports ICL communications to Sequent.
Specialised packages will be used for database archiving and retrieval,
work scheduling and automated monitoring, alerting and control of the
platforms and databases.
The CMS and PAS help desk application will be an ORACLE7 Client
that runs on a Windows NT platform.
OTHER COMPUTER & TELECOMMS EQUIPMENT
This will be described in more detail than that shown in the figure above
at a later level of specification following resolution of encryption
equipment and its connections.
Communications from each of the four ACCs to Pathway will be
concurrent file transfers of compressed data to both the Pathway
operational centres (Bootle and Wigan) via high speed WAN links.
These are expected to be 2Mbits/sec Megastream links. Each ACC will
have 2 routers/encryptors for resilience purposes. SMDS may be used in
preference to Megastream, but this is dependent upon the approved
encryptors being able to support the higher speeds of SMDS.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3C.DOC Page 88
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
For security purposes, ali data sent across the WAN will be encrypted
using the Rambutan mechanism, or other CESG approved method.
3.3 DSS SERVICE ENVIRONMENT
3.3.1 DSS COMPUTERS
The DSS operates a number of systems supporting the assessment and
calculation of the different benefit payments (in:this context these are
taken to include the-Social Security Agency (Northern Ireland) benefit
payments and the Employment Service payments for Income Support
and Unemployment Benefit).
The DSS has four Area Computer Centres (ACCs) which together cover
the UK interconnecting DSS offices and computer systems. Each ACC
has a number of computer systems supported on Ethernet segments.
Each ACC will have a CAPS system, holding benefit details by claimant’s
NINO, providing a consolidated service of benefit payment
authorisations and encashments across the UK. The ACCs are
interconnected via a national network (GDN) such that, in the event of a
failure, payment requests may be collected from the source systems in all
four ACCs and payment authorisations produced centrally at a single
CAPS system.
Rourer(s) WAN finks co Pathway
L] Bootle
Wigan
Encrypror(s)
Benefit Offices
Se TOBase-T
Job Centres
Aca Computer Centr (ACC)
Figure 3-7: Area Computer Centre
Each CAPS system operates on a large [CL VME mainframe running
OpenVME with the High Security Option. The schematic configuration
shown is replicated ateach of the four ACCs - Livingston, Norcross (near
Blackpool), Swindon and Washington.
The DSS issues benefit payment instructions (including payments stops)
from CAPS for action by the Pathway PAS, and Customer Details (e.g.
changed address) by the Pathway CMS. Pathway returns details of
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3C.DOC Page 89
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
3.3.2
3.3.2.1
benefit encashments, payment expiries, alerts and changes cf Nominated
Post Office to the DSS.
The DSS has contracted EDS to operate their IT services at the DSS Area
Computer Centres. Pathway will establish clear contractual agreements
with EDS as system manager for the CAPS service, as well as the DSS for
the provision of CAPS data.
BUSINESS OPERATING SYSTEMS AND SERVICES
BUSINESS SYSTEMS
CAPS Release 1 supports a batch interface. An on-line interface is a
stated future requirement. Pathway will implement a secure batch
Interface between CAPS and the PAS/CMS systems which has a number
of components:
© a secure partition within the CAPS VME processor to pick up/deliver
named files from/to CAPS and which runs a file transfer program to
control the transfer of CAPS files to and from the Pathway PAS and
CMS Oracle systems;
e high speed. WAN over which the File Transfer product operates;
e processes in the Pathway Central Services processors to carry out the
necessary record validation, logging, record formatting and delivery of
files to and from the PAS and CMS systems.
The processes at the CAPS end, and the file transfer product will be
capable of managing a range of file types. The processes within the
Central Services processors will be specific to the types of data
transferred.
The CAPS functions supported through the batch interface are as
follows:
e Send files of authorised payments and associated records to the
Pathway PAS/CMS systems
e Receive Confirmations (post validation in PAS/CMS) that files of
authorised payments etc. have been accepted (or rejected plus
individual record error reports)
e Receive files of encashmeni notifications and other records back from
PAS/CMS
e Maintain a log file which records every file transfer event, plus
reporting facilities
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3C.DOC Page 90
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
CAPS will place files ready for processing by PAS/CMS in “Out-Trays”
on their side of the partition and inform Pathway that these files are
ready for collection. The reverse process will take place for files and
messages from PAS/CMS to CAPS.
VME
BA Partition Pathway partition
Oo 8
Our
Trays
I rs ] [tees I I ne I 2 Mbits/sec
: - Router Crypto I >
I rl ute q rf
Figure 3-8: Operation of the CAPS interface
10 Base-T
[DN: The mechanism for CAPS and Pathway informing the other that files
are available needs to be defined.]
3.3.2.1.1 PROCESSES WITHIN CAPS COMPUTER
There will be a “CAPS Outbound Process” to handle files being
transferred from CAPS to PAS/CMS, and a “CAPS Inbound Process” to
handle files and messages received over the WAN which are placed in the
appropriate In-Trays on the CAPS side of the partition.
The CAPS file formats follow the simple structure:
© astandard Header record defining generic properties of the file;
e aseries of detail records;
a file specific Trailer record which contains all control items to ensure
functional integrity of the data.
3.3.2.1.2 FILE TRANSFER PRODUCT
This will be a proven, commercial product which in conjunction with
other components will support the following:
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3C.DOC Page 91
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
e file transfer management
¢ user program hooks
e transfer scheduling
¢ concurrent file transfers
e data compression
e data conversion
© security and integrity
e checkpoint/restart feature
e detect and report security violations
e auditability and control
e inbuilt statistics and audit trails
° remote management over network
* automatic reporting of succes:ful/unsuccessful transfers
"3.3.2.1.3 PROCESSES WITHIN CENTRAL SERVICES PROCESSORS
RUNNING PAS/CMS
The “PAS/CMS Inbound” process will receive files sent from CAPS, carry
out the necessary pre-processing for PAS/CMS, and load them into the
filestore in the Central Services processors.
The “PAS/CMS Outbound” process will take records/files from the
filestore in the Central Services processors, reformat them into the
required structure for CAPS and dispatch these to CAPS via the File
Transfer product.
3.3.2.2 BUSINESS SERVICES
The data transmitted between CAPS and the Pathway PAS/CMS systems
are defined in the DSS document “CAPS to PAS / CMS Data Interface
Definitions” (Version 5). There will be are up to 6,000,000 payment
authorisations per day.
3.3.2.2.1 FILES RECEIVED FROM CAPS - CAPS OUTBOUND PROCESS
CAPS files ready for processing will be held as named files in “Out-trays”
on the CAPS side of the secure partition in the VME mainframe.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3C.DOC Page 92
FUJ00119561
FUJO0119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 5/22/96
[DN: Pathway will be informed that a file is available, through a
mechanism which is yet to be defined, but is assumed to include a
message.]
1 The message is copied to a “file transfer log” with date and
time.
2 The file characteristics are logged
(file sequential number, file type, priority and number of records).
3 File level validation is carried out:
(a) Header Record checks:
The file characteristics are checked.
[DN: Detailed rules to be agreed.]
(b) Trailer Record checks:
e total record counts in files match trailer records
e sub-totals for each type of data group within each
record within the file match trailer values
¢ total financial value held within the file matches
¢ sub-totals.for each amount field within each record type
matches
(c) If the check fails, the DSS is informed by returning a
message giving the reason for failure (and the event logged)
4 Accepted files are passed to the file transfer product and
scheduled for transfer. This event is logged.
Where possible, this file validation will be carried out in line with the
transfer over the WAN.
3.3.2.2.2 FILE TRANSFER OVER WAN
The facilities listed in “File Transfer. Product” will be used to ensure
error free transmission. Data compression will be used, and a log file
will record file transfer events for audit trail and network statistics
purposes. Data sent across the WAN will be encrypted as advised by
CESG.
Scheduling transfers according to priorities, and file transfet procedures
in fall-back scenarios, will be automated. .
The file transfer mechanism will be visible and controllable at the central
network management centre.
3.3.2.2.3 FILES RECEIVED FROM CAPS - PAS/CMS INBOUND PROCESS
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3C.DOC Page 93
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 5/22/96
Files received within the Central Services processors will be validated by
PAS/CMS.
The results of the validation will be recorded in the log file, and a copy
sent to CAPS. Where all records submitted in the file from CAPS are
successfully validated, a single message giving the file sequence number,
time and date will be provided. Where individual records fail validation,
the failure reasons for the individual records, and their identifiers, will be
returned to CAPS.
The records will be re-formatted, e.g. the headers and trailer records
removed, to optimise the process of loading the records into the PAS
database. . There is no requirement to sort the Payment file.
3.3.2.2.4 FILES SENT TO CAPS -.PAS/CMS OUTBOUND PROCESS
Files which have been produced by the PAS/CMS database for onward
transmission to CAPS will be re-formatted into CAPS file formats (e.g.
insertion of headers and trailer records).
3.3.2.2.5 FILES SENT TO CAPS - CAPS INBOUND PROCESS
Files sent to-CAPS will be placed in the appropriate CAPS In-Tray, and a
message sent to CAPS (mechanism to be agreed).
The message, appropriately time and date stamped, and identifying the
file, will be entered in the log file.
3.3.2.3 HOUSEKEEPING
3.3.2.3.1 LOG FILE
A log file will be maintained, with consistent copies on each server. This
log file will be used to record file transfer events, and provide simple,
selective reports. It will be accessible from the central systems
management centre and will be used to analyse Pathway’s performance
and consistency with Service Level Agreements.
A means of selective archiving is required. A means of exporting the log
file to the Oracle database in the Pathway Warehouse is required.
3.3.2.3.2 VME DISK FILES
Printed: 22/05/96 COMMERCIAL-!N-CONFIDENCE
C:\FINALPRN\PFISCT3C.DOC Page 94
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: — 3.0
Date: 5/22/96
VME filestore with the capacity to retain 48 hours of data is required in
case re-runs are necessary. There is a requirement for Pathway to have
access to appropriate housekeeping tools (file maps, file deletes etc.)
unless such file copies are to’ be kept by the CAPS team.
Appropriate access by Pathway systems administration staff to the VME
partition is required to delete files as required.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT3C.DOC Page 95
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4. POCL SERVICE ARCHITECTURE
4.1 POCL STEADY STATE SERVICES
4.1.1 BENEFIT ENCASHMENT SERVICE
4.1.1.1 INTRODUCTION
This section refers to all BES transactions handled at the Post Office
counter.
The BES application provides support for all counter functions necessary
to support the distribution, issue and use of magnetic stripe based benefit
cards, BES will interact with the central CMS/PAS components of BPS
through the TMS and CMS/PAS agent(s) subsystems.
BES makes use of the Office Platform Service (OPS) and runs within the
general architecture of the POCL Service Infrastructure (PSI), using the
EPOS Service (EPOSS) for common underlying customer service
functions. Other counter applications will coexist alongside BES. In
particular, the Order Book Control Service (OBCS) and transaction
recording for paper based benefit payments will co-exist alongside BES
until the roll-out of the benefit card as the sole payment mechanism is
complete. -
A function or product shown in capitals, for example, ‘CARD RECEIPT’
refers to a menu button displayed on the screen. The required function
or product can then be selected by either touching the screen or using the
keyboard.
4.1.1.2 RECEIPT OF BATCH OF CARDS IN POST OFFICE
On receipt of the batch of cards at the post office, the manager swill check
that the batch is correct to the post office and, if so, sign for receipt of
the batch from the card carrier.
4.1.1.2.1 TRANSACTION SELECTION
The clerk will be required to read the bar-code on the batch of cards
with the bar-code reader in order to access the ‘Batch Receipt’ screen.
Exceptions:
1. Bar-code cannot be read:
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page 96
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
Clerk will select the ‘BATCH RECEIPT” option from the ‘Desktop’
menu and will then be prompted to key the bar-code information in
order to access the ‘Batch Receipt’ screen.
2. Keyed bar-code is not recognised:
Clerk will be prompted to check details have been keyed correctly and,
this being the case, to contact the CMS Help Desk.
4.1.1.2.2 STEADY STATE SERVICE PROVISION
Counter Activities
The ‘Card Receipt’ screen will display:
e FAD code
e Batch number
e Number of cards within the batch
The clerk will be prompted to confirm the FAD code and batch number
details are correct. This must be done immediately the batch is received
at the post office,
On indicating that the FAD code and batch number details are correct,
the clerk may either select the ‘CARD RECONCILIATION’ option to
reconcile the cards received against the batch details or return to the
‘Desktop’ menu.
Reconciliation of cards against batch details must be performed
immediately for urgent deliveries. Non-urgent deliveries must be
reconciled by 12 noon on day of receipt or, if received after 12 noon, by
end of day.
Exceptions:
1. Details on ‘Batch Receipt’ screen are incorrect:
Clerk will indicate that the FAD code and/or batch number are
incorrect and will be prompted to contact the CMS Help Desk.
Outputs
Acceptance of data on the “Batch Receipt’ screen will enable
- confirmation of batch receipt to be passed to CMS.
4.1.1.3 RECONCILIATION OF CARDS AGAINST BATCH DETAILS
The card reconciliation function may be invoked following receipt of the
batch, for audit purposes or after a contingency event of some kind
(suspected card loss or destruction) at the post office.
4.1.1.3.1 TRANSACTION SELECTION
Printed: 22/05/96. COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page 97
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
For a batch for which receipt has been confirmed, the clerk will be
required to read the Lar-code on the batch of cards with the. bar-code
reader in order to access the ‘Card Reconciliation’ screen.
Exceptions:
1. Bar-code cannot be read:
Clerk will select the ‘CARD RECONCILIATION’ option from the
‘Desktop’ menu and will then be prompted to key the bar-code
information in order to access the ‘Card Reconciliation’ screen.
2. Keyed bar-code is not recognised:
Clerk will be prompted to check details have been keyed correctly and,
this being the case, to contact the CMS Help Desk.
4.1.1.3.2 STEADY STATE SERVICE PROVISION
Counter Activities
The ‘Card Reconciliation’ screen wiil prompt the clerk to swipe each
card within the batch. On indicating that the last card has been swiped a
message will be displayed confirming that all:cards are present and
correct to the batch and the clerk will be returned to the ‘Desktop’ menu.
Exceptions:
1. Card fails to read when swiped:
Clerk will key the Primary Account Number (PAN) from the card.
2. Cards.are not all present end/or correct to batch:
Clerk will-be prompted to take the required action; for example, to
destroy card.
Outputs
Swiping of cards using the ‘Card Reconciliation’ screen will eriable details
of present, missing and excess cards within the batch to be passed to
CMS.
4.1.1.4 COLLECTION OF CARD BY CUSTOMER
The customer will present the Pick-Up Notice (PUN) or an existing card
which is due to expire in order to collect the benefit card.
4.1.1.4.1 TRANSACTION SELECTION
The clerk will be required to read the bar-code on the PUN or swipe the
existing card, for which a replacement card is available in the post office,
in order to access the ‘Card Activation’ screen.
Exceptions:
1. Customer advises that no PUN has been received:
Clerk will refer customer to CMS Help Desk.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE .
C:\FINALPRN\PFISCT4A.DOC Page 98
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.1.1.4.2
2. Customer has attended other than the nominated post office:
Clerk will be prompted to refer the customer to nominated post office
(Details of the customer’s nominated post office will not be displayed
on either the PUN or the screen).
3. Bar-code cannot be read:
Clerk will select the ‘CARD ACTIVATION’ option from the ‘Serve
Customer’ menu and will then be prompted to key the bar-code
information in order to access the ‘Card Activation’ screen.
4. Keyed bar-code is not recognised:
Clerk will be prompted to check details have been keyed correctly and,
this being the case, to impound the PUN and refer customer to BA
office.
5. Card withdrawn or expired prior to collection:
Clerk will be prompted to refer customer tu che BA office.
STEADY STATE SERVICE PROVISION
Counter Activities
The ‘Card Activation’ screen will display:
© Customer’s name
e Customer’s NINO
e Card batch number
The clerk will locate the customer’s card and check the name and NINO
on the card match those displayed on the PUN, or expired card, and
screen.
The clerk will be prompted to:
a) Verify the customer’s identity using the extended verification
procedure - see next section
b) Request proof of identity and record type of identity provided (not
required when an existing card is being replaced)
Where an existing card is being replaced, the clerk will be prompted to
retain and destroy the previous card
[DN: The proof of identity required will be same as currently required to
collect first issue of order book and could be stated on the PUN.]
On entering the appropriate verification information, the clerk will be
prompted to request signatures on the card and, where provided, the
PUN and then swipe the card. The clerk will swipe the card and will be
advised that the card has been successfully activated. After a short time
delay allowing the clerk to read the message, either the ‘Benefit
Encashment’ screen (if payments are due) or the ‘Serve Customer’ menu
(if no payments are due) will be accessed.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page 99
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
The activated card will be issued to the customer. Where a PUN has
been provided, the clerk will detach the guidance notes from the signed
portion of the PUN and return the guidance notes and proof of identity
to the customer. The signed portion of the PUN will be retained by the
clerk.
Exceptions:
1. Card cannot be located within post office:
Clerk will cancel transaction cnd refer customer to BA office.
2. Details on card do not match-those on PUN/expired card and/or
screen:
Clerk will impound card and PUN/expired card and refer customer to
BA office.
3. Expired card not provided:
Clerk will be unable to activate replacement card without expired
card, Customer will therefore be requested to return with expired
card, Should this be lost, customer will need to report card lost to
CMS Help Desk and PUN will be issued to enable collection of new
card.
4. No or insufficient proof of identity provided:
Clerk will advise customer to return with necessary documentation
and cancel the transaction.
5. No proof of identity recorded:
Clerk will be prompted to request and record proof of identity.
6. Clerk suspicious of proof >t identity provided:
Clerk will impound card and PUN and refer customer to BA office.
7. Card fails to read when swiped:
Clerk will key PAN, issue number and expiry date from the card.
Should card fail to be successfully read on three consecutive occasions,
a new card will be ordered automatically.
8. Card not successfully activated due to failed matching of PAN, Card
Activation Number or Sherman number:
Clerk will be prompted to check correct card has been selected and,
this being the case, impound card and PUN and refer customer to BA
office.
Outputs
Swiping of the card using the ‘Card Activation’ screen will enable details
of the successful or unsuccessful collection and activation of cards to be
passed to CMS.
4.1.1.4.3 CUSTOMER'S VIEWPOINT
The customer will present the PUN or expired card to the clerk. The
customer will be required to provide answers to verification questions
and, if PUN is presented, provide suitable proof of identity. The
customer will be requested to sign the PUN, if presented, and the card
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page 100
FUJ00119561
FUJ00119561
Pathway . Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
“gad will then be issued with an actis ated card which may be used for
benefit encashment. Expired cards will be retained by the clerk.
(DN: Discussion is required to determine whether a means of issuing an
unactivated card to a proxy for subsequent activation will be allowed.]
4.1.1.5 EXTENDED VERIFICATION PROCEDURE
The extended verification procedure will be invoked for payments that
are determined by DSS to be at risk of fraud. Such payments may
include, for example, foreign encashments, temporary tokens and card
read failures.
4.1.1.5.1 TRANSACTION SELECTION
At the appropriate time within the procedure the ‘Extended Verification’
screen will be accessed automatically or at the request of the clerk.
4.1.1.5.2 STEADY STATE SERVICE PROVISION
Counter Activities
The ‘Extended Verification’ screen will display one or more verification
questions. The clerk will ask the customer each question and key the
answers provided to the questions. On entering satisfactorily correct
answers to the questions, the clerk will be prompted to pay the benefit.
Pathway proposes that a single verification question is first asked. If this
is answered correctly then the transaction can continue. If the question
is answered incorrectly then two furt!:er questions will be displayed for
answer together in the same operation. If both of these are correctly
answered then the transaction can continue. If either or both of these
questions are incorrectly answered then the transaction is terminated.
[DN: Pathivay asstmes that verification qtiestions may comprise all
elements of address (including postcode) and date of birth as provided by
CAPS. Final details of available questions to be agreed with Contracting
Authorities.]
[DN: A number of options are available. Discussion and agreement is
required, ]
Exceptions:
1. Verification question(s) answered incorrectly:
Clerk will be prompted to suspend card/token and refer customer to
the BA office.
[DN: Suspension of card by clerk is not part of Contracting
Authorities’ requirements and requires agreement.]
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page 101
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
2. Clerk realises that answer to question has been incorrectly keyed:
Clerk will select ‘MIS-KEY’ option on screen and a further verification
question will be provided for customer to answer.
3. Customer is unable to answer verification questions due to
communication difficulties:
[DN: Whilst a number of options are available, agreement is required
with Contracting Authorities regarding such instances.]
4.1.1.5.3 CUSTOMER'S VIEWPOINT
The customer will provide answers to one or threé verification questions
asked by the clerk.
4.1.1.6 IMPOUNDMENT OF CARD/TEMPORARY TOKEN/PUN
4.1.1.6.1 TRANSACTION SELECTION
The clerk will be required to select one of the following options from the
screen currently in use:
‘IMPOUND PUN’
‘IMPOUND CARD AND PUN’
‘IMPOUND CARD/TEMPORARY TOKEN’
This may be in response to a system prompt or at the clerk’s discretion.
A card, PUN or temporary token will not be impounded by reason of it
having expired.
4.1.1.6.2 STEADY STATE SERVICE PROVISION
Counter Activities
Following the selection of the option to impound PUN and/or
card/temporary token, a receipt will be produced which the clerk will
sign and issue to the customer. The receipt will contain the following
details:
e Customer’s name
© Card detaiis (PAN, issue number and expiry date), PUN details (bar-
code number) or temporary token details (token number)
e Date and time
e FAD code
© Space for clerk signature
If a receipt for benefit encashment has been produced, the clerk will be
prompted to insert the receipt for overprinting as void and to retain it.
The clerk will refer the customer to the BA office.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page 102
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
If the impoundment is in response to a system prompt, for example, if a
stop has been placed on the card, the reason for the impoundment will
be automatically captured. If the impoundment has taken place at the
clerk’s discretion, the ‘Reason For Impoundment’ screen will be accessed
and the clerk will be prompted to indicate one of the following reasons
for the impoundment:
© Card defaced/altered
e Counterfeit card suspected
e Card does not-match PUN/screen details
e Suspicious mandate
e Suspicious proof of identity
e Poor signature match
e Customer left post office during transaction
° Other
The clerk will then be returned to the ‘Serve Customer’ menu.
The clerk will mark “Impounded” across an impounded PUN and
temporary token and holepunch the magnetic stripe on an impounded
card which will then be placed in a plastic bag. Impounded PUNs, cards
and temporary tokens will be retained by the clerk.
Outputs
Selecting the impound option following a system prompt, or indicating
why the card/temporary token was impounded on the ‘Reason For
Impoundment’ screen, will enable details of the impoundment to be
passed to CMS.
4.1.1.6.3 CUSTOMER'S VIEWPOINT
The customer will be advised that the PUN and/or card/temporary token
is to be impounded and a receipt will be issued. The customer will then
be referred to the BA office by the clerk.
4.1.1.7 FORWARDING/DISPOSAL OF PUNS, CARDS AND TEMPORARY
TOKENS
4.1.1.7.1 TRANSACTION SELECTION
The clerk will be required to select the ‘SUMMARY OF
CARDS/TOKENS’ or ‘SUMMARY OF PUNS’ option from the ‘Desktop’
menu.
4,.1.1.7.2 STEADY STATE SERVICE PROVISION
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page 103
FUJ00119561
FUJ00119561
Pathway. ... Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Counter Activities
The clerk will select from the ‘Summary Of Cards/Tokens’ screen the
reports which are required. Lists may be produced for the following
categories of cards/tokens:
a) Impounded cards/tokens; Counterfeit suspected
b) Impounded cards/tokens; Fraud (other than counterfeit suspected)
c) All impounded cards/tokens
d) Withdrawn/expired cards
The relevant impounded cards/tokens will be associated with the first
two lists and forwarded to the appropriate fraud departments. The third
list will be held in the post office for audit purposes. Should the clerk
have retained cards which do not.need to be forwarded to other
cepartments (for example, expired card retained on collection of
replacement card) these will be destroyed. The fourth list will provide
details of the batch number, customer name, PAN and issue number of
cards which have been withdrawn or expired prior to collection. Using
this list, the. clerk will locate the cards and destroy them.
(DN: The appropriate fraud departments, to which impounded
cards/tokens are forwarded to, require agreement with Contracting
Authorities.]
The clerk will select from th ‘Summary Of PUNs’ screen the reports
which are required. Lists may be produced for the following categories
of PUNs:
a) PUNs retained for activated cards
b) Impounded PUNs
Retained PUNs will be associated with the list and forwarded to the
PUN/receipt storage location. Impounded PUNs will be destroyed.
The screens will remind the clerk of where reports and associated items
should be forwarded to. Following the selection of the reports required,
the clerk will be returned to the ‘Desktop’ menu.
Exceptions:
1. Card on list cannot be located-within post office:
Clerk will contact CMS Help Desk.
Outputs
Selecting the reports required will activate the printing of the reports.
4.1.1.8 BENEFIT ENCASHMENT - STANDARD ENCASHMENT
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page 104
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
The customer will present own benefit card or temporary token‘at
nominated post office in order to encash benefit.
4.1.1.8.1 TRANSACTION SELECTION
The-clerk will be required to swipe the card through the card reader or
read bar-code on the temporary token with the bar-code reader in order
to access the ‘Benefit Encashment’ screen.
Exceptions:
1. Card/temporary token cannot be read:
Clerk will swipe card or read token again. If still not read, clerk will
select the ‘BENEFIT ENCASHMENT(CARD)’ or ‘BENEFIT
ENCASHMENT (TEMPORARY TOKEN) option from the ‘Serve
Customer’ menu in order to access the ‘Capture Of Card/Temporary
Token Details’ screen. The screen will prompt the clerk to key the
PAN, issue number and expiry dare from the card or key the number
from the temporary token. Should card fail to be successfully read on
three consecutive occasions, a new card will be ordered automatically.
. Keyed details not accepted:
Clerk will be prompted to check details have been keyed correctly and,
this being the case, to impound the card/token.
Ww
4.1.1.8.2 STEADY STATE SERVICE PROVISION
Counter Activities
Having swiped/read the card/token, the clerk will place the receipt in the
printer. The ‘Benefit Encashment *creen will display:
e Customer's name
e Customer’s NINO
¢ Details of outstanding benefit payments in chronological order,
including milk tokens as well as cash, together with the total amount
due
e Messages for clerk, if applicable
The receipt will be printed, which will be in English (English and Welsh
in Welsh speaking areas), and will contain the following decals:
Beneficiary’s name and abbreviated NINO
Date and time
PO code and clerk indicator
Benefit payment description and amount(s)
Total amount encashed
Milk token type and number
Predicted due date of next payment
eoeoee ae
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC. Page 105
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
e Allowed date for next allowablc foreign payment (where limit in
accordance with the set parameters has been reached)
Message. (where present)
Unique encashment transaction identifier
Unique clerk transaction identifier
Space for customer signature
Declaration of entitlement
Description of benefit types against type codes
[DN: Pathway requests confirmation that the requirement to state
© Predicted due date of next payment
e Allowed date for next allowable foreign payment
on the receipt remains valid.]
The clerk will check that:
¢ Card/token is authentic
e Customer name on system matches card/token
The clerk will provide the receipt to the customer for signature. The
screen will prompt the clerk to:
e Check signature on receipt matches that on card/token
© Issue bottom copy of receipt to the customer
e Retain top copy of receipt and, in the case of temporary tokens, token
The clérk will then:
e Check the signature on the receipt matches that on the card/token
e Pay customer, return card and issue bottom copy of receipt
© Commit the transaction and be returned to the ‘Serve Customer’
menu
e Place receipt and, in the case of temporary tokens, token in drawer
Exceptions:
1. Card/token is invalid (for example, stop placed on card, card
suspended, token time expired):
Clerk will be prompted to impound card/token and/or refer customer
to BA office.
2. No local match found for token:
Clerk will be prompted to check with customer that sufficient time has
elapsed since issue of temporary token for payment details to have
been received by the post office and, this being the case, to refer
customer to BA office.
. Outstanding benefits amount to more than the limit set by BA and
held as a reference value (currently £1,000):
Clerk will be prompted to ask whether the customer requires the full
amount or the amount at which the next payment, with payments in
chronological order, would take the encashment value over the
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page 106
FUJ00119561
FUJ00119561
Pathway. __ Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
reference limit. The screen will display the cut-off amount to assist the
clerk who will then select the amount for payment.
These rules do not apply to collection of Social Fund payments (which
must be collected in their entirety) or benefits for which customer is
alternative payee (which customer may choose not to collect).
4. Receipt not printed or spoilt in printing:
Clerk will request re-printing of receipt or, if printer is not working,
prepare manual receipt.
. No payment due:
Clerk will be prompted to advise customer that payment is not due
and return card to customer. In the evenit of dispute or enquiry, clerk
will refer customer to BA office. Should customer request receipt,
clerk will select ‘NIL RECEIPT’ option on screen in order to produce
receipt. The receipt will contain the following details:
e Header - Nil Receipt
e Beneficiary’s name and abbreviated NINO.
© Date and time
© FAD code and clerk indicator
¢ Predicted due date of next payment
¢ Allowed date for next foreign encashment (where limit has been
reached)
6. Customer decides does not want payment:
Clerk will cancel transaction and will be prompted to insert the receipt
for overprinting as void and to retain it. Clerk will then be returned
to ‘Serve Customer’ menu.
7. Clerk suspicious:
This may be an instance where extended verification procedure is
invoked. If suspicion is nor alleviated, clerk will impound card/token
and refer customer to BA office.
8. Customer unable to sign receipt: :
This may be an instance where extended veritication proceduré is
invoked. If clerk is suspicious, card/token will be impounded and
customer referred to BA office.
9. All or part of benefit is required as cheque payment:
Clerk will select ‘CHEQUE PAYMENT? option and input amount of
payment required by cheque.
10.Number of lines generated for encashment receipt exceeds number of
possible printable lines on receipt:
Clerk will be prompted to insert a second receipt slip for printing the
details it was not possible to print on first receipt. Slips will be.
numbered 1, 2, etc. and a single customer signature will be applied to
the final slip.
wn
Outputs
Committing transaction will record transaction details in the journal
record (forming part of audit trail), post details to EPOSS for cash
account and stock management purposes and enable details (including
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page 107
FUJ00119561
FUJ00119561
Pathway : Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
any flags; for example, keyed input. monitored card usage) to be passed
to PAS.
4.1.1.8.3 CUSTOMER’S VIEWPOINT
The customer will present own benefit card/token to the clerk at
nominated post office. The customer will be required to check and sign
a receipt for the benefit encashment and will receive payment and a copy
of the signed receipt.
4.1.1.9 BENEFIT ENCASHMENT - FOREIGN ENCASHMENT
The customer will present own benefit card at foreign post office in
order to encash benefit.
Tt is possible DSS may specify that an encashment may take place only in
either Great Britain or Northern Ircland. If the foreign encashment is
attempted in the wrong territory a further exception will be generated.
4.1.1.9.1 TRANSACTION SELECTION
The clerk will be required to swipe the card through the card reader in
order to access the ‘Benefit Encashment’ screen.
Exceptions:
As for Standard Encashment, where applicable.
4.1.1.9.2 STEADY STATE SERVICE PROVISION
Counter Activities
Having swiped the card, the clerk will place the receipt in the printer.
The ‘Benefit Encashment’ screen will be activated and the receipt will be
printed. The clerk will check that:
e Card is authentic
e Customer name on system matches card
The clerk will provide the receipt to the customer for signature. In
addition to the prompts regarding the receipt, the screen will display a
message that the transaction is being authenticated at the nominated post
office. The clerk will not make payment until this authentication has
taken place and, in response to the prompts on the screen, will:
e Check the signature on the receipt matches that on the card
© Pay customer, return card and issue bottom copy of receipt
e Commit the transaction and be returned to the ‘Serve Customer’
menu
e Place receipt in drawer
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page 108
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Exceptions:
As for Standard Encashment, where applicable, with the addition of the
following:
1. Restricted post office indicator applied:
Clerk will be prompted to refer customer to nominated post office
(Details of the customer’s nominated post office will not be displayed
on the screen).
2. Customer has reached limit of aliowable foreign payments:
Clerk will be prompted to advise the customer that further foreign
payments are not available unless change of nominated post office
takes place.
. Payment will take customer up to the limit of allowable foreign
payments:
Clerk will be prompted to advise the custo:er that this foreign
payment is last one allowed at present and provide date of next
allowable foreign payment.
4, Foreign encashment attempted in wrong territory:
Clerk will be prompted to advise the customer to encash the benefit in
the correct territory.
. Failure within customer’s nominated post office:
Clerk will make payment in accordance with details received from
TMS. Depending on the nature of the failure, there may be a risk of
double-payment i.e. communications failure may result in nominated
post office making payments using local authorisation data without
updating TMS, In the event of double payment, future benefit
payments will be re-scheduled in order to recover the over-payment.
w
wo
‘Outputs
Committing transaction will record transaction details in the journal
record (forming part of audit trail), post details to EPOSS for cash
account and stock management purposes and enable details (including
any flags; for example, keyed input, monitored card usage) to be passed
to PAS and to the nominated post cffice.
4.1.1.9.3 CUSTOMER'S VIEWPOINT
The customer will present own benefit card to the clerk at foreigit post
office. The customer will be required to check and sign a receipt for the
benefit encashment and will receive payment and a copy of the signed
receipt.
4.1.1.10 BENEFIT ENCASHMENT - CASUAL AGENT
The casual agent will present the beneficiary’s benefit card, own benefit
card and completed mandate at beneficiary’s nominated post office in
order to encash benefit. In the event that the casual agent does not have
own benefit card, proof of identity must be presented.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page 109
FUJ00119561
FUJ00119561
Pathway . Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.1.1.10.1 TRANSACTION SELECTION
The clerk will be required to swipe the beneficiary’s card through the
card reader in order to access the ‘Benefit Encashment’ screen.
Exceptions:
As for Standard Encashment, where applicabie.
4.1.1.10.2 STEADY STATE SERVICE PROVISION
Counter Activities
The clerk will check the beneficiary’s card, completed mandate and the
casual agent’s card/proof of identity. The mandate will contain the
beneficiary’s signature, which will be checked against the signature on
the beneficiary’s card, and the name of the casual agent, which will be
checked against the name on the casual agent’s card/proof of identity.
[DN: It is assumed that proof of identity required will be same as
currently required for casual agent to encash benefit and could be stated
on the mandate.}
Having swiped the beneficiary’s card, the clerk will place the mandate,
which forms the receipt, in the printer. The ‘Benefit Encashment’ screen
will be activated and the receipr will be printed. The clerk will check
that:
e Card is authentic
e Customer name on the system matches the card.
The clerk will then select the "CASUAL AGENT? option which will access
the ‘Casual Agent’ sereen.. The *C. Agent’ screen will prompt the
clerk to either swipe the casual agent’s card or request proof of identity
from casual agent and record the type of evidence provided.
On swiping the casual agent’s card or entering the type of evidence
presented, the ‘Benefit Encashment’ screen will be re-activated and the
clerk will provide the receipt to the casual agent for signature. The clerk
will then respond to the prompts on the screen and will:
e Pay casual agent, return beneficiary's card and casual agent’s
card/proof of identity, and issue bottom copy of receipt
e Prompt the customer to collect-a blank mandate for future use
e Commit the transaction and be returned to the ‘Serve Customer’
menu
© Place receipt in drawer
Exceptions:
As for Standard Encashment, where applicable, with the addition of the
following:
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A. DOC Page 110
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
i. No or insufficient proof of identity provided:
Clerk will refuse payment and request that casual agent returns with
appropriate proof of identity.
2. Clerk suspicious of proof of identity provided:
Clerk will suspend card and refer casual agent to BA office.
Outputs
Committing transaction will record transaction details in the journal
record (forming part of audit trail), post details to EPOSS for cash
account and stock management purposes and enable details (including
any flags; for example, keyed input, monitored card usage, casual agent)
to be passed to PAS.
4.1.1.10.3. CUSTOMER’S VIEWPOINT
The casual agent will present the beneficiary’s card, completed mandate
and proof of identity to the clerk at the nominated post office. The
customer will be required to check and sign a receipt for the benefit
encashment and will receive payment and a copy of the signed receipt.
4.1.1.11 BENEFIT ENCASHMENT - PERMANENT AGENT / ALTERNATIVE
PAYEE
The permanent agenr/alrernative payee will present own benefit card at
nominated/toreign post office in order to encash benefit. In the case of a
permanent agent, completed mandate(s) for each beneficiary on whose
behalf the agent is collecting will also be presented.
4.1.1.11.1 I TRANSACTION SELECTION
The clerk will be required to swipe the card through the card reader in
order to access the ‘Permanent Agent/Alternative Payee’ screen.
Exceptions:
As for Standard Encashment, where applicable.
4.1.1.11.2 STEADY STATE SERVICE PROVISION
Counter Activities
The clerk will check the card and, in the case of the permanent agent, the
completed mandate(s). Having swiped the card, the clerk will place the
receipt in the printer; in the case of the permanent agent, the mandate
will form the receipt. The ‘Permanent Agent/Alternative Payee’ screen
will display:
© Customer’s name
e Customer's NINO
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page 111
Pathway
FU,
Ref: PFS/PA/O0L
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
FUJ00119561
)JO0119561
4.1.1.11.3
e Selection of beneficiary’s payment(s) available for collection, which
may include own benefit payment
¢ Prompt to select beneficiary’s payment(s) to be collected and to check
any associated mandate(s)
The clerk will check that:
e Card is authentic
e Customer name on system matches card
and select the beneficiary’s payment(s) for collection. The selection of
payment(s) will activate the ‘Bencfit Encashment’ screen for the selected
beneficiary and the receipt will be printed. The cardholder’s name and
abbreviated NINO will appear on the receipt.
The clerk will provide the receipt to the customer for signature. In
response to the prompts on the screen, the clerk will:
e Check the signature on the receipt matches that on the card
Pay customer, return card and issue bottom copy of receipt
Prompt the customer to collect 2 blank mandate for future use
Commit the transaction
Place receipt in drawer
If payments for further beneficiaries have been selected for collection by
the permanent agent, the ‘Benefit Encashment’ screen for the next
beneficiary will be activated; otherwise, the clerk will be returned to the
‘Serve Customer’ menu
(DN: The principle of Group Permanent and Signing Agents - with the
provision of a single mandate for a number of beneficiaries and the
production of a single receipt - requires further discussion with the
Contracting Authorities.)
Exceptions:
As for Standard Encashment, where applicable.
Outputs
Committing transaction will record transaction details in the journal
record (forming part of audit trail), post details to EPOSS for cash
account and stock management purposes and enable details (including
any flags; for example, keyed input, monitored card usage) to be passed
to PAS and, if necessary, to the nominated post office.
CUSTOMER'S VIEWPOINT
The customer will present own benefit card and, where appropriate,
completed mandate(s). The customer will be required to select
payment(s) for encashment, check and sign receipt(s) for the benefit
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC. Page 112
Pathway
FUJ00119561
FUJ00119561
* Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.11.12
4.1.1.12.1
4.1.1.12.2
encashment and will receive paymcut(s) and a copy of the signed
receipt(s).
FORWARDING OF BENEFIT ENCASHMENT RECEIPTS
[DN: This section is provided as a starting point for discussions on
meeting the requirements of the DSS receipt storage and retrieval facility.]
TRANSACTION SELECTION
The clerk will be required to select the ‘SUMMARY OF ENCASHMENT
RECEIPTS’ option from the ‘Desktop’ menu.
STEADY STATE SERVICE PROVISION
Counter Activities
The clerk will select from the ‘Summary Of Encashment Receipts’ screen
whether a daily listing or weekly summary report is required and will
then be returned to the ‘Desktop’ menu.
The daily listing report will contain:
FAD code
Date and time (start and end of batch of receipts)
Counter position(s) to which the batch relates
Individual receipt details - NINO, encashment transaction identifier,
payment amount
Total number of receipts of each type (for example, standard, nil,
void, associated temporary tokens) produced during the day
The weekly summary report will contain:
e FAD code
e Individual daily listing report details: date, counter position(s), total
number of receipts
e Total number of receipts produced during the week
The clerk will collect together the receipts and temporary tokens for the
day’s transactions, which will have been stored in chronological order,
and check they are all present against the daily listing report. The
receipts and tokens will then be secured together with the report and
passed to the manager. The manager will place all the bundles in an
envelope which is marked clearly with the FAD code and date.
At the end of the week, the weekly summary will be produced. The
manager will place the summary report in a large envelope with the
enveloped receipts and daily listings. The large envelope is marked
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page Lid
FUJ00119561
FUJ00119561
Pathway Ref: PES/PA/OOL
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
os of receipts included and forwarded
clearly with the FAD code and d
to the receipt storage location.
Exceptions:
1. Receipts missing when checked against daily listing:
Clerk will locate missing receipts.
2. All daily listings not produced when weekly summary requested:
Clerk will be prompted to arrange completion of daily listings.
Outputs
Selecting the reports required will activate the printing of the reports.
4.1.1.13 DUPLICATE RECEIPT REQUEST
The customer will present own benefit card and request duplicate receipt
for last benefit encashed at attended post office.
4.1.1.13.1 I TRANSACTION SELECTION
The clerk will be required to select the DUPLICATE RECEIPT’ option
from the ‘Serve Customer’ menu and will then be prompted to swipe the
card which will access the ‘Duplicate Receipt’ screen.
Exceptions:
As for Standard Encashment, where applicable.
4.1.1.13.2 STEADY STATE SERVICE PROVISION
Counter Activities
Having swiped the card, the clerk will place the receipt, in the printer.
The ‘Duplicate Receipt’ screen will display:
e Customer’s name
e Customer’s NINO
and the receipt will be printed.
[DN: The wording, and period of time following encashment, for a
duplicate receipt require agreement with the Contracting Authorities. ]
The clerk will check that:
© Card is authentic
e Customer name on system matches card
The clerk will provide the receipt to the customer for signature. In
response to the prompts on the screen, the clerk will:
¢ Check the signature on the receipt matches that on the card
e Return card and issue bottom copy of receipt
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page Tid
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
e Commit the transaction and be returned to the ‘Serve Customer’
menu
e Place receipt in drawer
Exceptions:
As for Standard Encashment, where applicable.
Outputs
Committing transaction will record transaction details in the journal
record and enable details to be passed to PAS.-
4.1.1.13.3. CUSTOMER’S VIEWPOINT
The customer will present own benefit card and request duplicate receipt
for last benefit encashed at attended post office. The customer will be
required to check and sign the receipt and will receive a copy of the
signed receipt which will be marked “duplicate”.
4.1.1.14 CHANGE OF NOMINATED POST OFFICE
The customer will present own benefit card at new nominated post office
together with completed Change of nominated post oftice/address form
(PSOMA).
4.1.1.14.1 TRANSACTION SELECTION
The clerk will be required to select the ‘CHANGE OF NOMINATED
POST OFFICE’ option from the “Serve Customer’ menu and will then be
prompted to collect form and swipe the card which will access the
‘Change Of Nominated Post Office’ screen.
Exceptions:
As for Standard Encashment, where applicable, with the addition of the
following:
1. Restricted post office indicator applied:
Clerk will be prompted to refer customer to BA office.
4.1.1.14.2 STEADY STATE SERVICE PROVISION
Counter Activities
The clerk will check the completed Change of nominated post
office/address form (P80MA).
The ‘Change Of Nominated Post Office’ screen will display:
© Customer’s name
* Customer's NINO
© Messages for clerk, if applicable
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC. Page 115
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
The clerk will check that:
© Card is authentic
e Customer name on system matches card
The clerk will commit the transaction and will be advised that the
nominated post office has been changed. Any outstanding payments will
be re-located to the new office. After a short time delay allowing the
clerk to read the message, either the ‘Benefit Encashment’ screen (if
payments are due) or the ‘Serve Customer’ menu (if no payments are
due) will be accessed.
The clerk will forward completed forms to BA. Changes to address
details will be processed by BA using the forms.
Exceptions:
As for Standard Encashment, where applicable.
Outputs
Committing transaction record transaction details in the journal record
and enable details to be passed to PAS.
4.1.1.14.3 CUSTOMER’S VIEWPOINT
The customer will present ¢-vn benctit card to the clerk at néw office and
request change of nominateu post office.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4A.DOC Page 116
FUJ00119561
FUJ00119561
Pathway . Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.1.2 AUTOMATED PAYMENT SERVICE
4.1.2.1 INTRODUCTION
The Automated Payments Service (APS) is a service which enables POCL
to provide a range of payment services to the customers of many POCL
Clients including utility companies and local authorities.
These payment services are typified by their use of magnetic cards or
smatt tokens (cards or keys) which are presented by customers at the
counter either in support of payments or prepayments to their account.
APS transactions conform to the POCL APS Generic Rules, the Token
Technology specifications and the Automated Payments Client
Specification. APS counter transactions conform to the client specific
processing rules contained in these documents and utilise client reference
data which will specify details such as minimum payment amount, card
interpretation rules, specific receipt wording etc.
4.1.2.2 STEADY STATE SERVICE
Support for transactions for the following POCL Clients are included in
the Steady State APS. The supported customer token is shown, and all
APS transactions will produce a customer receipt.
Client Transaction “T Smart) Smart Receipt
L_Card Key Printer
BBC Easy Envry Y
Scheme
BT Payment Plan
Cable Cable TV v
companies _I Receipts
Electricity Payment Plans v
Companies L
Saving Schemes v
Smart Card Y v
schemes.
Smart Key v v
schemes
Gas Gas Meter 7 W
tokens
Saving schemes v v
Quantum Y vo
schemes.
Payment plans v W
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4B.DOC Page 1i7
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
. Date: 22/5/96
Client Transaction Mag. I Smart I Smart Receipt
Stripe Card Key Printer
Local Various Ww “ v
authority
Water Water savings v v
companies _I schemes
Payment plan v Y
Smart card v v
schemes.
Smart key v v
schemes
4.1.2.3 FUTURE OPTIONAL SERVICES
Pathway recognise that future growth may occur for this service with the
addition of new POCL Clients and the introduction of additional forms
of data capture, most notably the use by various utility companies of bar-
coded paper bills. Potential areas of service extension are shown as
below:
Client Transaction Bar] OCRor I OCR I Mag. I Smart I Smart I Receipt
H Code bar-code Stripe _I Card Key, Printer
.) BT Telephone receipts % %
Cable Cable TV Receipts Es Ea
Companies
Electricity Bill payment :
Companies \ i
Giro Transcash » I i
(i.e. bill payment)
Local Various
Authorities
Any extension of APS beyond the Steady State Service will be subject to
discussion and agreement between POCL and Pathway.
OCR support is an optional facility which must be selected in time to be
included in the equipment rollout.
4.1.2.4 APS FUNCTIONS
APS can be considered as comprising two groups of functions :
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4B.DOC Page 118
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
APS Host Functions
These are functions that relate to the receipt of Client data (reference
data updates, for example) and the storage/processing/dispatch of APS
transactions to the various Client systems.
APS Counter Functions
These are functions that relate to the tasks performed at the post office
counter that are specific to the processing of AP transactions. These
transactions, in common with all counter activity will use a set of generic
facilities (peripheral handling and initial data identification, for example)
together with a set of APS specific and Client specific processing.
Reference data filés will be used to determine how to interpret an APS
transaction and to supply any limits on processing (e.g. minimum
payment value). These functions are contained in the processing routines
and reference data files used by the Pathway counter system when
carrying out APS transactions.
Certain APS transactions are based around smart cards and keys. In
order to protect the integrity of data on these tokens the ability to read
and write requires the use of token specific code libraries.
Pathway requires that these will be supplied by POCL as executable
code.
4.1.2.4.1 APS HOST FUNCTIONS
The APS Host Functions will be provided on Pathway central systems
and will provide specific data storage and transaction handing functions
as required by POCL and POCL Clients. The operational characteristics
and technical requirements for these will be described in the set of
Automated Payments Client Specifications.
The generic functions are as follows:
Receive Client Reference Data
Steady State Service
This will comprise a batch dataflow from the POCL AP Host System and
/or a POCL Client system and will contain details of amendments and
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4B.DOC Page 119
FUJ00119561
FUJ00119561
Pathway Ref: PES/PA/OO!
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
additions to Client reference data. Such data will typically comprise
smart card tariff lists and /or stop lists.
A single daily dataflow will be supported from POCL and / or a POCL
Client. File-level validation and the recording of date / time for
operational control and service-level use will take place.
The complete operational characteristics, including the procedures for
success and error handling, and .he technical interfaces for these links
will be specified in the relevant AP Client Specification.
Future Optional Services
If new APS counter services are required, the nature of the AP transaction
may develop to include real time connections to support authorisation
requests and confirmations,
Receive TIP Reference Data
Steady State Ser
When the POCL TIP system is established, the APS Host system will
support a single daily dataflow of reference data additions or
amendments covering :
¢ Reference data about outlets for service management
¢ Reference data about AP tokens
e Reference data about AP clients
The record structures, technical interface and operational characteristics
is described in the POCL Interface Specification.
Interim Service
An alternative interface specification and technical implementation of the
APS Host system will need to be planned for should the TIP system not
be available in time.
Dispatch Client Data
Steady State Service
A daily batch dataflow will be provided to POCL and / or POCL Clients
which will comprise the transaction details of all AP transactions
conducted at the post office counter.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4B.DOC Page 120
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
The content of the transaction record will be Client specific and may
include some preprocessing (e.g. sorting, record layout, summary records
etc.).
The record structures, technical interface and operational characteristics
will be described in the relevant AP Client Specification.
Interim Service
The steady state service for dispatch of POCL data will operate to the
TIP system. An alternative interface specification and technical
implementation of the APS Host system will need to be planned for
should the TIP system not be available in time.
Future Optional Services
If new APS counter services are required, the nature of the AP transaction
may develop to include real time connections to support authorisation
requests and confirmations.
4.1.2.4.2 APS COUNTER FUNCTIONS
All Steady State AP transactions will be invoked using either a Magnetic
card or a Smart Card or Key. Certain transactions may also be invoked
via the touch screen & keyboard in the event of magnetic card or card
reader failure.
All steady state transactions are associated with crediting a customer
account, typically a traditional bill payment.
Using a magnetic card
The customer is supplied with a megnetic stripe card by the utility or
company to whom the bill is payable. The magnetic stripe contains
details of the customers account or reference number with the company.
This information is also embossed on the front of the card which may
also include a suggestion of the amount payable each month. The card is
swiped through the magnetic card reader and the account / customer
information on the card is read by the system and processed according to
the relevant Client reference data.
The value of the payment is keyed by the clerk and forwarded, with the
account / reference number to TMS for onward distribution to the client,
via POCL central systems. In addition to ‘crediting the customers account
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4B.DOC Page 121
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
in respect of any credit tariff agreed with the utility or company, ‘tokens’
may be purchased to be used in the customers gas / electric meter etc., if
required.
Tokens are value stock items. Stock records will be adjusted by the
system following every sale.
Using a Smart Card or Smart Key
Smart Cards or Smart Keys are ‘charged’ with a monetary value to enable
them to be used to credit utility meters (e.g. electricity or gas). The card
or key contains details of the customers account / reference number with
the utility or company. Following insertion into the card / key reader,
this information is read by the system, the amount payable is keyed by
the clerk and the card / key is then ‘charged’ with the value paid. The
value paid together with the customers account / reference number is
forwarded to TMS for onward distribution to the client via POCL
central systems.
Transaction Selection
e As the transaction selection is ‘Event driven’ i.e., the appropriate
screens are displayed following the swipe of a magnetic card or the
insertion of a Smart card / key into the reader.
¢ Jn the event that the magnetic card cannot be read due to a fault with
either the card or the reader, select ‘AP TRANSACTION’ ‘Serve
Customer’ screen,
* If the smart card/key or its reader fails chen the transaction cannot
take place.
4.1.2.5 STEADY STATE SERVICE
4.1.2.5.1 COUNTER ACTIVITIES
To complete the transaction the clerk is required to:
Magnetic Card
Swipe the card through the magnetic card reader.
¢ If card does not read, select the ‘AP’ application as above, and key
customers account / reference number in the required field
© Accept payment from customer
e Key the amount payable as instructed by the customer
e Select Method of Payment (MoP)
© Print transaction details on cheques using counter printer
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4B.DOC Page 122
FUJ00119561
FUJ00119561
Pathway - Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Issue. any tokens to the customer as required
Print receipt
Hand card, tokens and receipt to customer
Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Smart Card or Key
Insert the card or key into the reader
Accept payment from customer
Key the amount payable as instructed by the customer
Select MoP
Print transaction details on cheques using counter printer
Print receipt
Hand card and receipt to customer
Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
ee eeecee oe
4.1.2.5.2 OUTPUTS
The service will provide the following:
¢ Customer receipts
e Endorsed MoP (i.e. cheques)
® Cash Account postings
e Stock management of tokens
¢ Transaction details dispatched to POCL and/or POCL Client central
systems
e Recharged Smart card or Smart key
e POCL summaries
APS Receipts
A customer copy and an office copy receipt will be produced for every
APS transaction. The office copy receipt will be used to facilitate
transaction recovery in certain rare failure scenarios. Agreement will be
required on the tayout of APS receipts, the fixed and variable parts of the
layout, and the method of updating any Client specific information.
During the working day, and certainly by the close of business, all APS
transactions will have-been replicated to the central servers. There will
no longer be need based on contingency to retain APS receipts. POCL
may wish to retain receipts for reasons of customer service and a policy
will be required on this.
4.1.2.5.3 TRANSACTION RECOVERY
Pritited: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4B.DOC Page 123
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
. Date: 22/5/96
In a small number of cases it will be necessary for a post office to enter
transaction details that have occurred during a-period of failure. This
will typically occur when magnetic.card APS transactions have been
recorded manually, due to a PC failure. When the system returns the
clerk will be able to enter these transaction details, using the office copy
receipt, to ensure that client transaction data is captured and the stock-
unit cash position is correct.
4.1.2.5:4 TRANSACTION REVERSALS
APS transaction. reversals will be allowed for those transactions where
this facility is allowed within the reference data.
4.1.2.6 FUTURE OPTIONAL SERVICES
Optional services provided by Pathway in agreement with POCL will
include:
¢ Possible direct links with the client systems
e Support for additional transactions and data capture methods ar the
counter
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4B.DOC Page 124
FUJ00119561
FUJ00119561
Pathway ~~ Ref: PFS/PA/OO1L
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4.1.3 EPOSS COUNTER TRANSACTIONS
4.1.3.1 INTRODUCTION
This section describes how all non BA or non APS transactions are’
handled at the post office counter. Following reconciliation at the
counter they are posted to the journal and routed to POCL central
systems via TMS.
BA and APS transactions, whether automated or not link into EPOSS for
reconciliation and accounting purposes. *
This section also describes the:
e Customer Session
This allows the counter clerk to serve customers with any of the products
and services available, and gives a detailed description of the serving
process and system outputs required.
¢ Administration Functions
Including the Counter Administration and Office Administration
functions. .
4.1.3.1.1 STOCK ITEMS
“All value stock sales are transacted along the same principle. If more than
one item is required, the number required is keved prior to selecting the
product. If the product is selected first, the system defaults to show only
one item having been selected.
4.1.3.1.2 PRODUCT / SERVICE DISTRIBUTION AND AVAILABILITY
Not all post offices transact all products and services, e.g., DVLA licences
are restricted generally to Branch Orfices and Local Schemes are
geographically limited to particular areas.
Product and service distribution anJ-availability is controlled centrally.
Any attempt by an office to select a cisallowed transaction will result in
the system displaying a warning notice with any further continuation of
the transaction being prevented.
41313 TERMINOLOGY
Method of Payment - MoP
The MoP may be selected either:
¢ During the course of the transaction, when a specific transaction
related MoP requires this, e.g., Redeemed Stamps.
e Atthe end of the customer session when one MoP may be used to pay
for a number of transactions.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C. DOC Page 125
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
To illustrate a MoP has been chosen, this document shows MoP selection
during the processing of the transaction and not at the close of the
customer session.
A function or product shown in capitals, e.g. ‘GIROBANK DEPOSIT’
refers to a menu button displayed on the system screen. The required ~
function or product can then be selected by either touching the screen or
using the keyboard.
4.1.3.2 STANDARD PROCEDURES
4.1.3.2.1 COMPLETING POCL SUMMARIES
Where cheques, (including travellers cheques and Banker’s drafts), Giro
transfers, DNS warrants, postal orders and savings stamps have been
accepted as a MoP, the following summaries are printed by the OPS back
office printer:
P4630: Cheques
P884MA: — Inward Remirances (Giro transfers)
DNSS3MA : DNS Warrants
P492MA: _ Paid postal orders
P3731MA: Redeemed stamps
4.1.3.2.2 MOP
All transactions will assume cash t be the preferred MoP. The text
identifies thar the clerk must ‘Select MoP* only if cash is not tendered.
In addition to cash, cheques (including travellers cheques and bankers
drafts), Giro Transfers, DNS Warrants, Postal Orders, Savings Stamps
and EFTPOS can be accepted for payment. Certain transactions though,
have a pre-defined allowable MoP and this information will be held
centrally within the reference data.
4.1.3.3 CUSTOMER PERCEPTION
The customer will initially notice that the transaction is handled with an
increased level of efficiency and automation although the documentation
will remain largely unchanged. As the service develops , many of the
clerically completed forms may well be replaced with system printed
documents, e.g., the DVLA licence disk. Arrival at this level of
automation is dependent upon agreement being reached between
Pathway, POCL and the Client ata future date.
4.1.3.4 THE CUSTOMER SESSION
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 126
FUJ00119561
FUJ00119561
Pathway ... Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Transactions are services or products provided by the counter clerk to
the customer. The products range from simple fixed price items, such as
stainps, to complex open value transactions like the payment of benefits.
4.1.3.4.1 STOCK UNIT
The clerk must have a stock unit attached in order to serve a customer.
The facility to select and attach a stock unit to a user is contained within
the Counter Administration function. The customer session will clearly
display whether or nota user has a stock unit attached.
4.1.3.4.2 READY STATE
Before the start of a customer session the system will be in ‘ready state’.
Te will return to ‘ready state’ at the end of each session.
4.1.3.4.3 CUSTOMER SESSION LOG
The customer session comprises a set of transactions undertaken for the
same customer at one visit to the counter. In addition to ‘Serve
Customer’ selection options, the desktop will display an on-screen
Customer Session log and a running balance for settlement. This log will
show all of the transactions. within the customer session. The
information displayed will include the name, quantity, unit price and
total value as well as any indicators to show linked transactions. The
clerk, having arrived at this-point will then have the option to complete
the session or select another transaction.
Upon completion of the session, the final settlement is calculated, and
following input of the total cash amount tendered by the customer, any
change due is displayed.
4.1.3.4.4 STOCK UNIT STATUS
The desktop will display an on-screen stock unit status which will include
the stock unit ID and the total value of stock and cash held. The stock
unit contents will be maintained up-to-date during the serving process.
The display will show whether the stock unit is being ‘shared’ with other
users. (This identifies any team balancing).
4.1.3.4.5 DESKTOP TRANSACTIONS
The 16 most frequently used transactions will be made available on the
main desktop for rapid selection by the counter clerk.
4.1.3.4.6 OTHER TRANSACTIONS
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 127
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.1.3.4.7
4.1.3.4.8
4.1.3.4.9
4.1.3.4.10
4.1.3.4.11
4.1.3.4.12
4.1.3.4.13
Those transactions not on the maiti desktop will cither be automatically
invoked by the occurrence of an appropriate event such as a magnetic
card swipe, or by navigation through a menu comprising a hierarchy of
desktops.
MODIFY A TRANSACTION
It will be possible to modify a transaction within a customer session that
has not been committed. The counter clerk will select the transaction
from the session log.
VOID A TRANSACTION
Ir will be possible to cancel a transaction within.a customer session that
has not been committed. The counter clerk will select the transaction
from the session log.
SETTLE AND COMMIT A TRANSACTION
The system will determine whether or not a transaction must be settled
in it’s own right, e.g., Benefit Encashments.
ABANDON A CUSTOMER SESSION
It will be possible to abandon a customer session before settlement is
_ reached. Transactions which nave aiready been settled cannot be
abandoned although they may be reversed, (if they are reversible). When
a transaction is abandoned the system will return to ‘ready state’.
SESSION SETTLEMENT
The session settlement in the form of a running balance to be paid in or
paid out will always be displayed. The allowable methods of payment for
each session will be dependent upon the actual transactions contained
within the session. The system wil! enforce a set of rules for a transaction
which will determine what method of payment is allowable for that
transaction.
END CUSTOMER SESSION
The end of the current customer session will return the system to ‘ready
state’. It will be possible to end a session only when the balance is set at
zero, following the settlement process.
COMMIT TRANSACTIONS
Transactions will generally be committed once the session has been
completed, this action will result in the transaction information being
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 128
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
posted to the journal thereby providing a full audit trail. However,
certain transactions, e.g., BA, will mandate settlement and committing in
their own right within the session to allow encashment details to be
transmitted to PAS preventing further encashment.
4.1.3.4.14. CONTINUE A CUSTOMER SESSION
A customer session may be continued following the end of the session.
4.1.3.4.15 I START A NEW CUSTOMER SESSION
A new customer session is started when the first-transaction for the new
customer is invoked.
4.1.3.4.16 I SUSPEND AND RESUME CUSTOMER SESSION
More than one customer session may be kept going at any one time on
the same terminal by the same counter clerk. One or more customer
sessions may be suspended whilst other customers are being served.
4.1.3.4.17 PRINT A SESSION RECEIPT
An optional session receipt may be printed at the end of the customer
session prior to the start of the next session. Certain transactions, APS
and BA, will require receipting in their own right and the system will
force the production of such a ree*“pr, either in mid-session if other
transactions are also required, or «i the end of the session if these
transactions are in isolation.
4.1.3.4.18 I PRINT A DUPLICATE RECEIPT
The clerk will be able to re-print any number of duplicate receipts for the
last customer session after the end of the session and prior to the start of
the new customer session. These receipts will be marked as ‘Duplicate’.
4.1.3.5 INPAY - DNS DEPOSIT
This application allows the following transactions:
Open new Ordinary account
Open new Investment account
Deposit to existing Ordinary account
Deposit to: existing Investment account
Purchase Capital Bonds
Purchase Children’s Bonus Bonds
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 129
Pathway Ref:
DSS/POCL Functional Specification Version:
Date:
FUJ00119561
FUJ00119561
PFS/PA/OOL
3.0
22/5/96
4.1.3.5.1 TRANSACTION SELECTION
The clerk will be required to select:
e ‘DNS DEPOSIT’ from ‘Serve Customer’ menu.
e Selecting the transaction type.
4.1.3.5.2 STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk will be required to:
e Accept and check documentation and payment
Key DNS-account number
Key surname of investor
Key Value of transaction
Select MoP
printer
Print transaction details on cheques and warrants using counter
e Clerically endorse cheques and warrants with non-system data as
applicable to transaction ‘vpe
e Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
e Manually update passbook (if required)
Outputs
The service will provide the foilowing:
e Cash Account postings
e DNSS3MA summary
e DNSS6MA sumimary
e DNSS4MA summary
e¢ POCL summaries
4.1.3.5.3 FUTURE OPTIONAL SERVICES
Optional services to be provided by Pathway in agréement with POCL
will include:
© Subject to an on-line link to DNS, the updating of passbooks using the
counter printer
e Code-line swipe of transaction detail from deposit documents
4.1.3.6 INPAY - GIROBANK DEPOSIT
This application allows the following transactions :
e A&L Giro personal account deposit
e A&L/SWINDON building society deposits
e Girobank cash handling deposit
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC
Page 130
FUJ00119561
FUJ00119561
I
Pathway Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Girobank Transcash bill paymeny
Girobank merchant voucher deposits
Girobank corporate / A&L Giro cheque deposit envelopes
Premium bond purchases .
National Savings certificate purchases
4.1.3.6.1 TRANSACTION SELECTION
The clerk will be required to select:
e ‘GIROBANK DEPOSIT’ from ‘Serve Customer’ menu
e Transaction type, e.g., ‘TRANSCASH’ from the ‘Girobank Deposit’
screen (This is necessary to ensure the correct PIVOT code is applied
for remuneration and charging purposes.)
4.1.3.6.2 STEADY STATE SERVICE PROVISION
Counter Activities
The clerk will be required to:
e Accept and check documentation and payment
Key Account number :
Key Value
Key Fee (if applicable)
Key reference number (if required)
Select “MoP’
Print transaction details on cheques, transfers and warrants using
counter printer
e Select ‘COMPLETE’ to return ts “Serve Customer’ menu
Outputs
The service will provide the following:
e Cash Account postings
e G4631 summary
¢ G4633 summary
© POCL summaries
4.1.3.6.3 FUTURE OPTIONAL SERVICES
Optional services provided by Pathway in agreement with POCL will
include:
e Automatic calculation of fee - linked to account number
© Account number directory - linked to various POCL ‘schemes’
e Code-line swipe of transaction details
4.1.3.7 INPAY / STOCK SALE NON RETAIL - DVLA
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C. DOC. Page 131
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
This application allows the renewal of MVL licences using the V10 or
V11 documentation and the purchase of Temporary First Licences. The
V11 form is received by the customer direct from DVLA and can be used
at qualifying Post Offices to. obtain a new licence disk, providing details
regarding the vehicle and the customer are current. V10 renewals are
actioned when a V11 has not been received or details regarding the
vehicle or the customer have changed.
Licence disks are value stock itc.ns recorded by serial number, not value.
Stock records will be adjusted by the system following every sale.
4.1.3.7.1 TRANSACTION SELECTION
The clerk will be required to select:
e ‘LICENCES’ from ‘Serve Customer’ menu
e ‘DVLA’ from ‘Licences’ menu
4.1.3.7.2 STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk is required to:
e Accept and check documentation, (MOT etc.) and payment
e Key the licence disk serial number
e Key the prefix number (tu selec: the licence period)
e Key the taxation class of the vehicle, (along with the prefix number
above, this will select the appropriate duty payable)
e Select MoP
e Print transaction details on cheques and transfers using counter printer
e Cancel redeemed DVLA stamps if offered as MoP
e Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
e Manually endorse the licence disk with the vehicle registration
(including the validation character), taxation class, make of vehicle,
period of taxation, rate of duty payable, and weight, cc, seats, and
trailer weight if required. Spoilt licences are recorded on the system by
Selecting ‘SPOILT’ .
¢ Complete the required sections within the V10 and V1 forms
Outputs
The service will provide the following:
e Cash Account postings
e Stock management
e V10 schedule (V594)
e Vi1 schedule (V595)
e V5S70 summary
e¢ POCL summaries
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page I
FUJ00119561
FUJ00119561
Pathway - Ref: PES/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4.1.3.7.3 FUTURE OPTIONAL SERVICES ‘
Optional services provided by Pathway in agreement with POCL will
include:
e Extended data input to include all information required on the licence
disk enabling the printing of the licence disk using the counter printer.
4.1.3.8 INPAY / STOCK SALE NON RETAIL - TV LICENCE RENEWAL
There are 3 ways in which to renew a TV licence:
eA standard renewal with the renewal form received by the customer
direct from NTVLRO
e A renewal using an ‘application’ form obtained at the Post Office, this
can also be used for the initial purchase of a TV licence
e A renewal by exchanging an existing black. and white licence for a
colour licence
The standard renewal and the renewal using the application form are
essentially the same in the detail required by the TV licence application.
The main differences lie within the clerical procedures required to
complete the documentation.
TV licence stamps are value stock items. Stock records will be adjusted
following every renewal.
4.1.3.8.1 TRANSACTION SELECTION
The clerk: will be required to select:
e ‘LICENCES’ from ‘Serve Customer’ menu
e ‘TV’ from ‘Licences’ menu
4.1.3.8.2 STEADY STATE SERVICE PROV!SION
Counter Activities
To complete the transaction the clerk will be required to:
© Accept and check documentation and payment
© Select ‘COLOUR’ or ‘MONO’ for licence type
© Select MoP
e Print transaction details on cheques and transfers using counter printer
e Cancel redeemed stamps if offered as MoP
e If refund of black and white licence, select ‘REFUND’ and key value
of refund.
If a reduction is required for a blind person, select ‘BLIND’
@ Select ‘COMPLETE’ to return to.‘Serve Customer’ menu
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 133
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4.1.3.8.3
4.1.3.9
4.1.3.9.1
4.1.3.9.2
e Attach TV licence stamp to ticcuce form
© Complete relevant sections of licence form
Outputs
The service will provide the following:
e Cash Account postings
e Stock management
¢ POCL summaries
FUTURE OPTIONAL SERVICES
Optional services provided by Pathway in agreement with POCL will
include:
© Provision of a refund table within the system - accessed by input of the
expiry date of the surrendered black and white licence. This would
calculate the refund due
INPAY - OTHER LICENCES - ROD & GAME
Licences may be purchased «t che Post Office for:
e To deal in game
e¢ Gamekeeper
e To kill game - Red, Green, Blue, Occasional
¢ Rod - Salmon or Trout
Although licences are not classed a¢ value stock, spoilt licences must be
recorded on the Cash Account
TRANSACTION SELECTION
The clerk will be required to select:
e ‘LICENCES’ from ‘Serve Customer’ menu
e ‘GAME’ or ‘ROD’ from ‘Licences’ menu
STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk will be required to:
Game licence
e Accept and check documentation and payment
e Select type of licence required from menu
e Complete licence
¢ Select MoP
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 134
FUJ00119561
FUJ00119561
Pathway . Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date 22/5/96
¢ Print transaction details on cheques and transfers using counter printer
© Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Issue licence to customer
e Hold counterfoil then forward to Local Council Game Officer
e Select ‘SPOILT’ if licence is damaged
Rod Licence
© Accept and check documentation and payment
Select type of licence required from menu
Select ‘CONCESSION’ if required
Complete licence
Select MoP
Print transaction details on cheques and transfers using counter printer
Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Issue licence to customer
Enter details of licence on the weekly sales summary
Complete weekly reconciliation «f licences
Select ‘SPOILT’ if licence is damaged
Outputs
The service will provide the following:
© Cash Account postings
e¢ POCL summaries
4.1.3.9.3 FUTURE OPTIONAL SERVICES
Optional services provided by Pathway in agreement with POCL will
include:
e Print weekly sales summaries
4.1.3.10 INPAY / OUTPAY - WESTERN UNION
The money transfer service via Western Union can be used to either send
or receive money to or from abroad.
4.1.3.10.1 TRANSACTION SELECTION
The clerk will be required to select:
¢ ‘OTHER PRODUCTS’ from ‘Serve Customer’ menu
© “WESTERN UNION’ from ‘Other Products’ menu
« ‘SEND’ or ‘RECEIVE’ as applicable.
All relevant telephone numbers will be displayed on the screen to assist
the clerk when telephoning the Western Union Control Centre to
authorise transactions.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C. DOC Page 135
FUJ00119561
FUJ00119561
Pathway - - Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.1.3.10.2 STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk will be required to:
Sending Money Abroad
© Accept payment from customer
e Check the customer has completed all relevant sections of the ‘Send
Money’ form - if the value is over £350 a description of the payee
must be obtained
Select additional services and calculate the handling charge
Select MoP
Print transaction details on cheques using counter printer
Telephone Western Union control centre (obtain number from
directory) and verify ID
© Give customer details, obtain authorisation code from control centre
e Clerically endorse cheque with guarantee card number and
authorisation code
¢ Complete sections within ‘Seid Money’ form
e Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Receiving Money from Abroad
e Ensure customer has completed the relevant sections of the ‘Receive
Money’ form .
e Check customer’s ID - and enter on form
e Telephone control centre and verify ID
© Give customer details and obtain authorisation code from control
centre
e Enter authorisation code on “Receive Money’ form
¢ Select ‘COMPLETE? to return to ‘Serve Customer’ menu
© Complete relevant sections of "Receive Money’ form, hand one copy
to customer and retain bottom copy
e Pay customer
Outputs
The service will provide the following:
e Cash Account postings
¢ POCL summaries
4.1.3.10.3 FUTURE OPTIONAL SERVICES
Optional future services to be provided by Pathway and agreed with
POCL will include:
e Possible direct link tc Western Union to avoid the need for verbal
telephone authorisation
e Full data entry of customer and transaction detail
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 136
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
e Data entry of guarantee card details
e Guarantee card details printed on cheques and transfers
4.13.11 INPAY - INSURANCE PRODUCTS
Two types of travel insurance policies are offered by POCL in
conjunction with General Accident, the ‘Single Trip’ and ‘Annual’
policies.
Customers must either complete an application form or verbally give
details to the clerk to enable the 3 part policy document to be
completed.
4.1.3.11.1. TRANSACTION SELECTION
The clerk will be required to select:
e ‘OTHER PRODUCTS’ from “Serve Customer’
e ‘INSURANCE PRODUCTS’ from ‘Other Products’ menu
4.1.3.11.2 STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk is required to:
e Accept payment from customer
Complete the policy document
Key amount
Select MoP
Print transaction details on reverse of cheques using counter printer
Select ‘COMPLETE’ to return to ‘Serve Customer’ screen
Record office details, teller ID, MloP and Cash Account week on
policy document
¢ Request customer checks details on document, if correct:
- give white copy to customer
- forward yellow copy to Chesterfield
- retain pink copy in office
e Staple customer application forn, <o pink copy
Outputs
The service will provide the following:
e Cash Account postings
e POCL summaries
4.1.3.11.3 I FUTURE OPTIONAL SERVICES
Optional services to be provided by Pathway and agreed with POCL will
include:
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 13
FUJ00119561
FUJ00119561
Pathway ..-: Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
¢ Possible data entry of customers details to provide automatic
production of the policy document
4.1.3.12 INPAY - RENT PAYMENTS
This application allows rent payments using either rent cards or rent
vouchers at post offices nominated by the local authority or housing
association.
4.1.3.12.1 TRANSACTION SELECTION
The clerk will be required to select:
« ‘OTHER PRODUCTS ‘< from ‘Serve Customer’ menu
e ‘RENT PAYMENTS’ from ‘Other Products’ menu
4.1.3.12.2 I STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk will be required to:
e Check PO is nominated tc accept payments
Accept and check documentition and payment
Key amount
Select ‘CARD PAYMENT’ or “VOUCHER PAYMENT’
Select ‘MoP’
Print transaction details on cheques and transfers using counter printer
Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Initial customer's payment card ‘card payments only)
Date stamp voucher and counterfoil (voucher payments only)
Return card or voucher counterfoil to customer
Complete rent collection schedule
Complete Transcash deposit slips (end of period)
e cere oe ee oo
Outputs
The service will provide the following:
e Cash Account postings
4.1.3.12.3. FUTURE OPTIONAL SERVICES
Optional services provided by Pathway in agreement with POCL will
include:
e System printing of the Rent collection schedules for card payments
and voucher payments for each Girobank account
e System printing of Transcash deposit slips for each Girobank account
e Girobank account number directory and selection
e Transaction acceptance at PO - linked to Girobank account number
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 138
FUJ00119561
FUJ00119561
Pathway ~~ Ref: PPS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
¢ MoP acceptance - linked to Girovank account number
e Code-line swipe of transaction details from rent card/voucher
4.1.3.13 INPAY - BUNCHES - FLOWERS BY POST
This application allows bunches of flowers to be ordered for despatch
within 48 hours by first class post.
4.1.3.13.1 TRANSACTION SELECTION
The clerk will be required to select:
¢ ‘OTHER PRODUCTS ‘ from ‘Serve Customer’ menu
e ‘FURTHER OTHER PRODUCTS’ from ‘Other Products’ menu
e ‘BUNCHES - FLOWERS BY POST? from ‘Further Other Products’
menu
4.1.3.13.2 STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk will be required to:
e Accept and check documentation and payment
© Select products required
¢ Select ‘TODAY’ or ‘NEXT DAY’ to determine client summary which
will include the transaction (depends on when order may be placed
with Bunches)
Key amount
Select ‘MoP”
Print transaction details on cheques and transfers using counter printer
Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Date stamp order form and counterfoil
Return counterfoil to customer
Telephone order to Bunches
Enter reference number allocated by Bunches on order form
Outputs
The service will provide the following:
e Cash Account posting (as Girobank Transcash payment)
e Girobank Summary completion (es Girobank Transcash deposit)
@ POCL summaries
4.1.3.13.3. FUTURE OPTIONAL SERVICES
Optional services provided by Pathway in agreement with POCL will
include:
© Code-line swipe of transaction selection from order form
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 139
FUJ00119561
FUJ00119561
I
Pathway... Ref: “PES/PA001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.1.3.14 INPAY - BRITISH TELECOM BILL PAYMENT
This application is designed specifically for the payment of British
Telecom bills which differ from all other paper bill payments because:
e They do not require a PIVOT code
e British Telecom is not a customer of Girobank and therefore does not
use Transcash documentation
The application is capable of accommodating similar transactions should
any-new business be won by the Post Office in the future.
4.1.3.14.1 I TRANSACTION SELECTION
Tie clerk will be required to select:
e Event driven form code-line swip? of bill payment counterfoil.
e ‘BT BILL PAYMENT? from “Serve Customer’ menu.
4.1.3.14.2 I STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk is required to:
e Accept and check documentation and payment
Key Value
Key account number if code-line swipe fails
Select MoP
Print transaction details on cheque and transfers using counter printer
Cancel redeemed stamps if offered as MoP
Select ‘COMPLETE? to return to “Serve Customer’ menu
eooe ee
Outputs
The service will provide the following:
e Cash Account postings
¢ Telephone Accounts Paid summary
e POCL summaries
4.1.3.14.3 FUTURE OPTIONAL SERVICES
Optional services provided by Pathway in agreement with POCL will
include:
e Extension of service to other clients
4.1.3.15 OUTPAY - DNS WITHDRAWALS
This application allows the following transactions:
Printed: 22/05/96. COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 140
FUJ00119561
FUJ00119561
Pathway ~ Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
Cash withdrawals from Ordinary accounts
Warrant withdrawals from Ordinary accounts
Warrant withdrawals from Investment accounts
Special withdrawals
Deposit Bond warrants
Savings Certificate warrants
Save As You Earn warrants
Yearly Plan warrants
Children’s Bonus Bond warrants
Premium Savings Bond warrants
Capital Bond warrants
Income Bond warrants
4.1.3.15.1 I TRANSACTION SELECTION
_ The clerk will be required to select:
e ‘DNS WITHDRAWAL’ from ‘Serve Customer’ menu.
With the exception of a direct cash withdrawal from.an Ordinary
account, all other ‘withdrawals’ are cash payments made against DNS
warrants issued direct to the customer. The different transactions are
identified by a 2 or 3 digit warrant code.
4.1.3.15.2 STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk is required to:
e Accept and check documentation
Check value limits for Ordinary account cash withdrawals
Key surname of investor
Key warrant code (if applicable)
Key Value
Select ‘COMPLETE?’ to return to “Serve Customer’ menu
Update passbook for Ordinary account withdrawals
Pay customer
eoe ec eee
Outputs
The service will provide the following:
Cash Account postings
DNS53MA summary
DNSS6MA summary
DNSS4MA summary
POCL summaries
Printed: 22/05/96 ~ COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 141
FUJ00119561
FUJ00119561
Pathway ~~ Ref: PES/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.1.3.15.3. FUTURE OPTIONAL SERVICES
Optional services provided by Pathway in agreement with POCL will
include:
© Subject to an on-line link with DNS, the update of the Ordinary
account passbook using the counter printer
© Code-line swipe of transaction detail from withdrawal documentation
or warrant
4.1.3.16 OUTPAY - GIROBANK WITHDRAWAL
This application allows the following transactions:
A&L Giro personal account withdrawal
A&L Giro Linksave account withdrawal
A&L/ SWINDON building society withdrawal
Girobank business cash withdrawal
Girobank Cashcheque withdrawal
Postcheque encashment
West German savings bai.k withdrawal
Withdrawals without cheques
Cashing other banks cheques (not a Girobank transaction but uses this
application)
oe eo ee oe e
4.1.3.16.1 TRANSACTION SELECTION
The clerk will be required to selee::
e ‘GIROBANK WITHDRAWAL’ from ‘Serve Customer’ menu.
e Transaction type, ¢. “A&XL GIRO’ from the ‘Girobank Withdrawal’
screen. (This is necessary to ensure the correct PIVOT code is applied
for remuneration and charging purposes.)
4.1.3.16.2 STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk will be required to:,
e Accept and check documentation
Telephone AXL Giro and request authorisation code for payment
Key account number
Key Value
Key Fee (cashing other banks cheques only)
Key Authorisation code (for Linksave & withdrawals without cheques)
Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Pay customer
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C. DOC Page 142
FUJ00119561
FUJ00119561
“Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
. Date: 22/5/96
e Endorse withdrawal documentation with guarantee card / postal
authority card details if required by transaction
Outputs
The service will provide the following:
© Cash Account postings
© G4632 summary
e POCL summaries
4.1.3.16.3. FUTURE OPTIONAL SERVICES
Optional services provided by Pathway in agreement with POCL will
include:
e Data entry of guarantee card details
¢ Withdrawal document endorsement with guarantee card details
e Standard fee calculation (COBC)
¢ Code-line swipe of transaction detail from withdrawal documents
4.13.17 OUTPAY - BENEFIT ENCASHMENT USING FOIL (NON-OBCS)
The customer will present order book at post office without OBCS, or
order book without bar-code at post office with OBCS, in order to
encash benefit.
4.1.3.17.1. TRANSACTION SELECTION
The clerk will select “BENEFIT ENCASHMENT (FOIL)’ option from the
‘Serve Customer’ menu order to access the ‘Benefit Encashment (Foil)
screen.
4.1.3.17.2 5 STEADY STATE SERVICE PROVISION
Counter Activities
The ‘Benefit Encashment (Foil)’ screen will prompt the clerk to check the
payment stop-list and, provided customer is not listed, pay the customer
and enter payment details.
To complete the transaction the clerk will be required to:
Check order book and foil(s)
Check manual stop-list
Date stamp foil(s) and counterfoil(s)
Remove foil(s) from order book
Return book tv customer
Key payment details: Benefit group, foil amount, number of foils
(default of one) and number of milk tokens
@ Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 143
FUJ00119561
FUJ00119561
Pathway. .... Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
e Pay customer
Exceptions:
e Stop placed on order book:
Clerk will select ‘IMPOUND?’ option, key NINO from order book, hole-
punch book and return it to BA.
e Matured recall notice placed on order book:
Clerk will encash allowed payments, select ‘IMPOUND’ option, key
NINO from order book, hole-punch book and return it to BA.
© Clerk suspicious:
Clerk will impound book. Clerk will select ‘IMPOUND’ option, key
NINO from order book, hole-punch book and return it to BA.
© All or part of pavment is required as cheque payment:
Clerk will select ‘CHEQUE PAYMENT? option and input ~mount of
payment required by cheque.
Outputs
¢ Cash Account postings
e Daily Pensions & Allowances I's:
« Weekly Pensions & Allowances summary
e Number of foils encashed
Note
Other exceptions, in addition to those listed and which arise-at present,
will continue to be handled in the same way. .
4.1.3.18 OUTPAY - BENEFIT ENCASHMENT USING GIROCHEQUE
The customer will present Girocheque(s) at post office in order to encash
benefit.
4.1.3.18.1 TRANSACTION SELECTION
The clerk will select ‘BENEFIT ENCASHMENT (GIROCHEQUE)’
option from the ‘Serve Customer’ menu order to access the ‘Benefit
Encashment (Girocheque)’ screen:
4.1.3.18.2 STEADY STATE SERVICE PROVISION
Counter Activities
The ‘Benefit Encashment (Girocheque)’ screen will prompt the clerk to
check the payment stop-list and, provided customer is not listed, pay the
customer and enter payment details.
To complete the transaction the clerk will be required to:
e Check Girocheque(s)
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C. DOC Page 144
Pathway
Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4.13.19
© Check stop-list
Date stamp Girocheque(s)
Key payment details: Girocheque amount, number of cheqnes (default
of one) and number of milk tokens
e Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
e Pay customer
Exceptions:
e Violet Girocheque(s) presented:
Clerk will select “NI’ option prior to committing transaction.
Outputs
e Cash Account postings
e Girocheque summary
Note
Other exceptions, in addition to those listed and which arise at present,
will continue to be handled in the same way.
MISCELLANEOUS TRANSACTIONS
This relates to simple transactions where there is only < requirement to
identify the transaction and the MoP for Cash Account and
reconciliation purposes. The screen presented identifies each transaction
by Icon / Button. If the transaction relates to an INPAY, the screen allows
the input of the appropriate MoP.
Transactions included in this application:
INPAY
© Lottery sales
© Scratch card sales
Bus Permits
Local Schemes
Passport Applications
ET11
Telemessages
Active Life Renewals
Mobile Phone Handset Sales
Commemorative Coins
Scratch Card Sales
Meal Voucher Receipts
OUTPAY
¢ Prescription Refunds
¢ Co-op Cheque Encashment
e ATM withdrawals
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 145
FUJ00119561
FUJ00119561
FUJ00119561
FUJ00119561
Pathway .. Ref: PFS/PA/OO1L I
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
e Lottery Pay-outs
e Scratch card Pay-outs
e MOD pensions
Financial & Reconciliation Administration
e Error notices
e Pre paid mail
e Franking Machine Re-setting
e Unpaid Cheques
2 Unclaimed Payments
e Uncharged Receipts
4.1.3.19.1 TRANSACTION SELECTION
The clerk will be required to select:
e “OTHER PRODUCTS’ from ‘Serve Customer’ menu
e ‘OTHER’ from the ‘Other Products’ menu
4.1.3.19.2 STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk will be required to:
e Select transaction type
Accept documentation
If INPAY - Accept payment
If INPAY - Select MoP
Print transaction details on checues and transfers using counter printer
If OUTPAY - Pay customer
Select ‘COMPLETE? to return to “Serve Customer’ menu
Outputs
The service will provide the following:
e Cash Account postings
e POCL summaries
4.1.3.19.3 FUTURE OPTIONAL SERVICES
Optional services provided by Pathway in agreement with POCL will
include:
e Extension of data capture as necessary
4.1.3.20 STOCK NON RETAIL - 1ST & 2ND CLASS POSTAGE STAMP
SALES
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C. DOC Page 146
FUJ00119561
FUJ00119561
Pathway ‘ Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: I 3.0
Date: 22/5/96
ist & 2nd class postage stamps have been given their own product
bution within the ‘Serve Customer’ screen as they are understood to be
common transactions which need to be completed quickly.
Postage stamps are value stock items. Stock records will be adjusted by
the system following every sale.
Uprating & Downrating
Postage stamp values r.ay be changed by ihe Post Office at the close of
business of the current. Cash Account week. New values should be
charged at the commencement of the new Cash Account week. If this
occurs the stock unit values will be amended by the system and the
appropriate value posted to the Cash Account as ‘Uprating’ or ‘ Down
rating’.
4.1.3.20.1 TRANSACTION SELECTION
The clerk will be required to select:
e ‘IST CLASS POSTAGE STAMP? or ‘2ND CLASS POSTAGE STAMP’
from ‘Serve Customer’ menu.
4.1.3.20.2 STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk will be required to:
e Accept payment from customer
e [fa single stamp is required of vither denomination - Select the
appropriate value
e If more than one stamp is required of either denomination - Key the
number required and then select the appropriate value
° Select MoP
e Print transaction details on cheque and transfers using counter printer
© Clerically endorse cheques and transfers with guarantee card / postal
authority card details
© Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Outputs
The service will provide the following:
e Cash Account postings
e Stock management
© POCL summaries
4.1.3.20.3. FUTURE OPTIONAL SERVICES
Optional services provided by Pathway in agreement with POCL will
include:
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 147
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
e Data entry of guarantee card / postal authority card details
e Guarantee card / postal authority card details printed on cheques and
transfers
4.1.3.21 STOCK NON RETAIL / INPAY - OTHER MAILS
This application allows the purchase of:
© Postage stamp books
¢ Postage stamp rolls
e Postage stamp discount books
© Single or multiple postage stamps of denominations other than Ist or
2nd class
© Royal Mail / Parcelforce Inland mail services
© Royal Mail / Parcelforce International mail services
Postage stamps are value stock items. Stock records will be adjusted
following every sale.
Uprating & Downrating
Discount Stamp values may be changed by the Post Office at the close of
business of the current Cash Account week. New values should be
charged at the commencement of the new Cash Account week. If this
occurs the stock unit values will be amended by the system and the
appropriate value posted to the Cash Account as ’Uprating’ or
‘Downrating’.
4.1.3.21.1 TRANSACTION SELECTION
The clerk will be required to select "OTHER MAILS’ from ‘Serve
Customer’ menu, allowing a selection of:
© Book of 4 Ist class stamps
e Book of 10 Ist class stamps
e Book of 4 2nd class stamps
e Book of 10 2nd class stamps
e Roll of 100 Ist class stamps
© Roll of 200 Ist class stamps
© Roll of 100 2nd class stamps
© Roll of 200 2nd class stamps
e Discount Books - 25 Ist class
¢ Discount Books - 50 1st class
e Discount Books - 25 2nd cla
e Discount books - 50 2nd cia
e Other Postage Stamps - leading to a sub menu of denominations
e Inland Mail - leading to a sub menu of services
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 148
FUJ00119561
FUJ00119561
Pathway . Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
e International Mail - leading to a sub menu of services
4.1.3.21.2 I STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk will be required to:
Postage stamp books, rolls or discount stamp books:
e Accept payment from customer
e If asingle item is required - Select the appropriate item
e If more than.one item is required - Key the number required and
select the appropriate item
e Select MoP
e Print transaction details on cheques and transfers using counter printer
@ Clerically endorse cheques and transfers with guarantee card / postal
authority card details
© Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Other Postage Stamps
On selecting this product, the screen will display all available
denominations plus the currently available commemorative issues.
© Accept payment from customer
e Ifa single stamp is required - Select the appropriate denomination
e If more than one stamp is required - Key the number required and
then select the appropriate denomination
e Select MoP
e Print transaction details on cheques and transfers using counter printer
e Clerically endorse cheques and <ransfers with guarantee card / postal
authority card details
© Select ‘COMPLETE’ to return to “Serve Customer’ menu
Inland Mail / International Mail
On selecting either product, the screen will display all available and
associated services.
Weigh package
Select Service
Accept payment from customer
Affix priority service label (if applicable to package)
Complete all relevant details on priority label
Select Postage, (if payable) - this will take the clerk into a window
allowing the selection of postage stamps
Select ‘COMPLETE’ to return to ‘Mails’ screen
Select MoP
Print transaction details on cheques and transfers using counter printer
Clerically endorse cheques and transfers with guarantee card / postal
authority card details
© Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 149
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Outputs
The service will provide the following:
e Cash Account postings
e Stock management of postage stamps
e POCL summaries
4.1.3.21.3 FUTURE OPTIONAL SERVICES
Optional services provided by Pathway in-agreement with POCL will
include:
e Data entry of guarantee card / postal authority card details
e Guarantee card / postal authority card details printed on cheques and
transfers
e¢ A comprehensive data base of tariffs for both Inland and International
mails
STOCK NON RETAIL - BT TELEPHONE CARD SALES
There are 5 types of BT Tele shone card which may be purchased at the
Post Office:
20 units £2
SOunits £5
100 units £10
200 units £20
Collectors packs
BT Telephone cards are value stock items. Stock records will be adjusted
by the system following every sale.
4.1.3.22.1. TRANSACTION SELECTION
The clerk will be required to select:
e ‘BT TELEPHONE CARDS’ from ‘Serve Customer’ menu
4.1.3.22.2. STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk will be required to:
© Accept payment from customer
© Ifa-single card is required of any denomination - Select the
appropriate value
e If more than one card is required of any denomination - Key the
number required and then select the appropriate value
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 150
FUJ00119561
FUJ00119561
Pathway - Ref: PFS/PA/OUL
DSS/POCL Functional Specification Version 3.0
Date: 22/5/96
e Select MoP
e Print transaction details on cheques and transfers using counter printer
e Clerically endorse cheques and transfers with guarantee card / postal
authority card details
e Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Outputs
The service will provide the following:
e Cash Account postings
e Stock management
e POCL summaries
4.1.3.22.3. OPTIONAL FUTURE SERVICES
Optional services provided by Pathway in agreement with POCL will
include:
e Data entry of guarantee card / postal authority card details
e Guarantee card / postal authority card details printed on cheques and
transfers
4.1.3.23 STOCK NON RETAIL - SAVINGS STAMP SALES
Savings stamps can be purchased for:
Gas
Electricity
Water
Telephone
Home Help
Active Life
TV Licence
DVLA Licence renewal
eoeoceoeeee
Savings stamps are value stock items. Stock records will be adjusted by
the system following every sale.
4.1.3.23.1 TRANSACTION SELECTION
The clerk will be required to select:
e ‘SAVINGS STAMPS’ from ‘Serve Customer’ menu
4.1.3.23.2. STEADY STATF SERVICE PROVISION
Counter Activities
To complete the transaction the clerk will be required to:
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 151
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
e Accept payment from customer
e Ifa single stamp is required of any type - Select the appropriate stamp
type
e If more than one stamp is required of any type - Key the number
required and then Select the appropriate type
e Select MoP
e Print transaction details on cheques and transfers using counter printer
e Clerically endorse cheques and transfers with guarantee card / postal
authority card details
e Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Outputs
The service will provide the following:
e Cash Account postings
e Stock management
e POCL summaries
4.1.3.23.3. FUTURE OPTIONAL SERVICES
Optional future services provided by Pathway in agreement with POCL
will include:
e Data entry of guarantee card / postal authority card details
¢ Guarantee card / postal authority card details printed on cheques and
transfers
4.1.3.24 STOCK NON RETAIL - POSTAL AND MONEY ORDERS
Postal Orders are available in the following denominations - 50p, £1, £2,
£3, £4, £5, £6, £7, £8, £9, £10, £15, £20. Each postal order can be
increased in value up to 49p by affixing up to 2 postage stamps. A fee is
payable for each postal order depending upon the value.
Redemption
Postal Orders must always be redeemed, if not attached to the purchase
of any product or service e.g., DVLA licences, for cash. If they are used
to purchase a product or service, although physical cash will not
be exchanged with the customer, their value is treated as cash for the
purposes ot reconciliation.
Fees
Postal orders and their fees are classed as value stock items and are linked
together, therefore when a postal order is sold the system will apply the
appropriate fee. Upon completion of the transaction, the system will
update the stock records to reflect the sale.
If more than one postal order is purchased, the appropriate fees must be
charged. If a single postal order is required but cannot be supplied due to
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 152
FUJ00119561
FUJ00119561
* Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
unavailability of stock, and more than one postal order is therefore
supplied, only one fec is charged. The clerk can therefore overwrite the
fees calculated by the system.
If the counter clerk spoils a Postal Order during preparation, e.g., tears
the order, this must be accounted for within the Postal Order stock unit.
In addition to cancelling the spoilt order, the associated fee must be
cancelled. Spoilt orders should be entered on the Inward Rems summary
as ‘Spoilt stock’
Uprating
Postal Order fees may be changed by the Post Office at the close of
business of the current Cash Account week. New fees should be charged
at the commencement of the new Cash Account week. If this occurs the
stock unit values will be amended by the system and the appropriate
value posted the Cash Account as ‘Uprating’.
Money Order Redemption
There is no facility to purchase International Money orders, although
Canadian and USA money orders can be encashed at any Post Office.
4.1.3.24.1 TRANSACTION SELECTION
The clerk is. required to select:
e ‘POSTAL/MONEY ORDERS’ from ‘Serve Customer’ menu
e ‘POSTAL ORDER PURCHASE’, ‘POSTAL ORDER REDEMPTION’,
or ‘INTERNATIONAL MONEY ORDER REDEMPTION’ from
e ‘Postal / Money Orders’ menu.
4.1.3.24.2 STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction, the clerk will be required to:
Postal Order Purchase
e Accept payment from customer
e Select Value of Postal Order(s) required
e Select ‘POSTAGE’
e Key Value of stamps required if intermediate value
e Key Value of fee charged - (if fee needs amendment due to
unavailability of P.O. denomination requested)
© Select MoP
¢ Print transaction details on cheques and transfers using counter printer
¢ Clerically endorse cheques and transfers with guarantee card / postal
authority card details
¢ Issue Postal Orders
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C. DOC Page 153
FUJ00119561
FUJ00119561
I
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date 22/5/96
e If Postal Orders spoilt - select “>POILT? and re-commence transaction
e Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Postal Order Redemption
e Key the Value of Postal Orders redecmed
© Key the Value of postage stamps
e Pay customer
International Money Order Redemptior
© Key the value of the Money order redeemed
e Select the country of origin - USA / CANADA
e Pay customer
e Enter Canadian orders on the Canadian money order claim form
Outputs
The service will provide the following:
© Cash Account postings
¢ Stock management
e¢ POCL summaries
4,.1.3.24.3 FUTURE OPTIONAL SERVICES
Optional services provided by Pathway in agreement with POCL will
include:
e Data entry of guarantee card / postal authority card details
e Guarantee card / postal authority card details printed on cheques and
transfers
e Print the Canadian money order claim form
4.1.3.25 STOCK NON RETAIL - PHILATELIC PRODUCTS
A simple application allowing the sale of philatelic products - first day
covers, special edition stamps etc.
Philatelic products are classed as value stock. Stock records will be
adjusted following every sale.
4.1.3.25.1 TRANSACTION SELECTION
The clerk will be required to select:
e¢ ‘OTHER PRODUCTS’ from ‘Serve Customer’ menu
e ‘PHILATELIC’ from the ‘Other Products’ menu
4.1.3.25.2 STEADY STATE SERVICE PROVISION
Printed: 22/05/96 COMMERCIAL-iN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 154
FUJ00119561
FUJ00119561
Pathway. ... Ref: PFS/PA/O1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Counter Activities
To complete the transaction the clerk is required to:
e Accept payment from customer
¢ Ifa single philatelic product is required - Select the appropriate
product
¢ If more than one unit of a particular product is required - Key the
number required and then select the appropriate product
© Select MoP
e Print transaction details on cheques azd transfers using counter printer
© Clerically endorse cheques and transfers with guarantee card / postal
authority card details
© Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Outputs
The service will provide the following:
e Cash Account postings
e Stock management
e POCL summaries
4.1.3.25.3 FUTURE OPTIONAL SERVICES
Optional future services provided by Pathway in agreement with POCL
will include:
e Data entry of guarantee card / postal authority card details
e Guarantee card / postal authority card details printed on cheques and
transfers
4.1.3.26 STOCK NON RETAIL - BUREAU DE CHANGE
The Bureau de change service is available at selected Post Offices and
offer, (up to certain pre-defined limits) the facility to:
Exchange foreign currency for £ sterling
Exchange £ sterling travellers cheques for £ sterling
Exchange foreign travellers cheques for # sterling
Purchase foreign currency
Purchase £ sterling travellers cheques
eoeee
4.1.3.26.1 TRANSACTION SELECTION
The clerk will be required to select:
e ‘OTHER PRODUCTS’ from ‘Serve Customer’ menu
e ‘BUREAU DE CHANGE?’ from ‘Other Products’ menu
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 15°
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date 22/5/96
4.1.3.26.2 STEADY STATE SERVICE PRO'ISION
Counter Activities
To complete the transaction the clerk will be required to:
If purchase, accept payment from customer
Complete transaction on ‘Forde’ machine
Key £ sterling value of the transaction
Select transaction type - ‘Purchase £ sterling travellers cheque’ etc.
Select MoP
Print transaction details on cheques and transfers using counter printer
Clerically endorse cheques and transfers with guarantee card details
Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
If exchange for £ sterling, pay customer
Outputs
The service will provide the following:
e Cash Account postings
e POCL summaries
4.1.3.26.3 FUTURE OPTIONAL SERVICES
Optional future services to be provided by Pathway and agreed with
POCL will include:
e Migration of the ‘Forde’ system onto the counter system
e On-line links to currency conversion information
e Data capture of cheque guarantee card details
e Guarantee card details printed on cheques and transfers
4.1.3.27 STOCK - NON RETAIL: FIRST RATE CURRENCY
Customers wishing to order foreign currency from Post Offices not
offering the full Bureau de Change service. A buy back service is also
available up to £100.
4.1.3.27.1 TRANSACTION SELECTION
The clerk will be required to select:
e ‘OTHER PRODUCTS’ from the ‘Serve Customer’ menu
e ‘FIRST RATE? from the ‘Other Products’ menu
4.1.3.27.2. - STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk will be required to:
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C.DOC Page 156
FUJ00119561
FUJ00119561
Pathway ‘ Ref: PFS/PA/001
. DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Pre-Order
© Accept and check documentation and payment
Select ‘PRE-ORDER’
Work out commission - (include express handling charge if required)
Telephone order if express delivery is required
Select MoP
Print transaction details on cheques and transfers using counter printer
Clerically endorse cheques and transfers with guarantee card details
Select ‘COMPLETE’ to return to ‘Serve Customer’ menu
Complete ‘Receipt of Order’ form
Pass top copy of receipt to customer
Despatch order to First Rate
e@o5eee cee ee
Complete customer collection procedures when customer arrives to
collect order. No system operations required.
Buy Back
Accept documentation and currency/cheques from customer
Select ‘BUY BACK’
Calculate buy back
Complete ‘Foreign Exchange Buy Back’ form
Pay customer
Place cheques or currency in envelope
Outputs
The service will provide the following:
e Cash Account postings
¢ POCL summaries
4.1.3.27.3. FUTURE OPTIONAL SERVICES
Optional services to be provided by Pathway in agreement with POCL
will include:
e Data capture of guarantee.card details
e Guarantee card details printed ori cheques and transfers
4.1.3.28 STOCK RETAIL - POST SHOP PRODUCTS
Items for sale in the Post shop can also be purchased over the counter at
the same time as any other products and services. Post shop items are
treated the same as receipts for accounting purposes, however they are
physical stock items which are ‘managed’ separately from the main
counter stock included within the clerks stock unit.
Any Post Shop purchase over the counter will have the effect of
increasing the Cash or other MoP. To ensure correct accounting a
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C. DOC Page 157
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
separate line has been included within the Receipts table of the Cash
Account, giving the total value of all Post Shop classified items sold.
4.1.3.28.1 TRANSACTION SELECTION
The clerk will be required to select:
e The selection will be event driven following the scanning of the bar
code on or applicable to the item sole This bar code will be
recognised as applying to a Post Shop product and the system will
access the Post shop screen.
e Failure to read the bar code will require selection of ‘OTHER
PRODUC7S’ from ‘Serve Customer’ menu
© ‘POST SHOP’ from ‘Other Products’ menu
4.1.3.28.2 STEADY STATE SERVICE PROVISION
Counter Activities
To action the transaction the clerk is required to:
e Accept payment from customer
@ Ifasingle item of a particular type is required - Swipe bar-code or
Select Post Shop product, as above and key bar code number
e If more than one item of a particular type is required - Key number
required then swipe bar code or Select Post Shop product, as above,
key number required then key bar code number
e Select MoP
e Print transaction details on cheques and transfers using counter printer
© Clerically endorse cheques and transfers with guarantee card details
e Select ‘COMPLETE’ to return co ‘Serve Customer’ screen
Outputs
The service will provide the following:
e Cash Account postings
e Data transfer to Post Shop stock management system
¢ POCL summaries
4.1.3.28.3 FUTURE OPTIONAL SERVICES
Optional services provided by Pathway ir . sreement with POCL will
include:
e Data entry of guarantee card details
e Guarantee card details printed on cheques and transfers
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4C. DOC Page 158
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.1.3 ADMINISTRATION FUNCTIONS
4.1.3.1 LOG ON
All users will be given a level of access to the system as determined by
their position within the office. For example, counter clerks will be
limited to serve customer and simple balance and reconciliation
applications, whilst managers will be given access to the whole range of
counter and office administration functions.
All users will be allocated a password which will require changing at pre-
determined periods. This action will be prompted by the system although
a lower level password may be changed by the office manager if
necessary, e.g., when a password has been forgotten by the user. A
facility will be ptovided to enable a sole user who has forgotten his
password to gnerate a unique key which is telephoned through to the
OPS Help Desk. A corresponding key is given to the office manager,
which when entered into the system, will allow access to the
administration screen from where the password can be re-set. Office
managers will require their passwords to be changed, by the appropriate
Local Security Officer.
A similar mechanism to the above will be used for POCL auditors, with
the result giving access to the Audit screen.
Successful and unsuccessful attempts to log on will be recorded by the
system. This information will be recorded along side the FAD code,
counter position and the date & time.
An external visitor, such as the RETAIL: Network Manager could be
given access to the system by the office manger.
[DN: Discussion and agreement is required on the possible use of smart
card for user sign-on.]
4.13.11 FUNCTION SELECTION
The log on screen will be displayed following switch on of the terminal.
Counter Activities
The clerk will be required to:
e Key unique ID
° Key Password
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 159
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
System Response
e The system will identify the current stock unit, if any, that is attached
to the user.
« The system will clean up or recover any information processed prior
to any abnormal termination of the user’s previous session possibly
due to failure.
The user will be presented with the main desktop showing:
Help and Messages
First level functions provided by Riposte.
Serve Customer Functions
Allowing all transactions to be completed at the counter.
Counter Administration
Allowing stock unit attachment, balancing, tr. isfers and remittances in
and out.
Office Administration
Allowing stock unit administration, cash account production, report
generation and remuneration.
Log Out
Log out will end the user’s session at the counter.
Temporary Lock
This will allow the user to secure and leave the counter position
temporarily. The lock will prevent unauthorised use of the absent user’s
terminal. [t will be removed by entering the user’s password.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 160
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.1.3.2 COUNTER ADMINISTRATION
This section describes the counter administration facilities.
4.1.3.2.1 SHARING A STOCK UNIT
Sharing a stock unit results when a stock unit is attached to more than
one user at one time. When sharing a stock unit a number of users will
be able to divide the administrative functions between themselves, e.g.,
the declaration of cash and stock on hand may be carried out by each
user
and each declaration will represent that user’s proportion of the total for
the stock unit which will be used for balancing purposes.
4.1.3.2.2 ATTACH A STOCK UNIT
This will allow the user to select a stock unit for their use with the
following constraints:
e The stock unit must exist
e The user must not have a stock unit already assigned
e Tf it is not sharable - the unit must not be attached to another user
e If it is not sharable - the stock unit must be in a balanced state
4.1.3.2.3 START A NEW STOCK UNIT BALANCE PERIOD
After attaching’ stock unit ro a user a new balance period is opened “and
started. All operations involving the stock unit are included within this
balance period until the stock unit is balanced again.
4.1.3.2.4 DETACH A STOCK UNIT
This will allow the user to relinquish responsibility for the stock unit
under the following conditions:
© The stock unit is attached to a user
e If the stock unit is not being shared it must be in a balanced state
4.1.3.2.5 STOCK TRANSFERS
Stock can be transferred between stock units in the following way:
e The requesting user, the user receiving the stock, will verbally agree
with a sending user on the quantity and value of the stock required
e The requester will make the transfer request
e The sender will respond with a ‘Transfer Out’ confirmation
© The sender gives the requester the agreed items
e The requester responds with a ‘Transfer In’ confirmation
Transfer Request
The transfer request will be made using the system
Transfer Out
Printed: 22/05/96 COMMERCIAL-iN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC. . Page 161
FUJ00119561
FUJ00119561
{
Pathway — Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
The sender will use the ‘TRANSFER OUT’ function to view and confirm
the quantity and value for each stock item. When completed a ‘Transfer
Our slip is printed by the sender using the counter printer. This process
generates transfer out transactions and decreases the stock unit’s levels.
Transfer In
The requester will use the ‘TRANSFER 'N’ function to view and
confirm the quantity and value for each stock item to be taken in. When
this is completed a ‘Transfer In’ information slip is printed by the
requester using the counter printer. This process generates transfer in
transactions and increases the stock unit’s levels.
Transfer Completion
The physical exchange of stock is accompanied by the signing of the
‘Transfer Out’ receipt by the requester. The sender keeps the signed
receipt as proof of the transaction.
4.1.3.2.6 REMITTANCES IN / OUT
Stock remittances occur:
¢ Between two outlets, when one outlet requests a replenishment of
stock from another nearby
¢ When an outlet orders stock from the CRU
e When an outlet returns stock to the CRU
Remittance In / Out
The requesting outlet, the outlet receiving the stock, will verbally agree
with the sending outlet or CRU on the quantity and value of stock
required.
The requesting outlet will make the remittance request
The sending outlet or CRU will respond with a ‘Remittance Out’
confirmation
The sending outlet or CRU gives the requesting outlet the agreed items
The requesting outlet responds with a ‘Remittance In’ confirmation
Remittance Request
Tle remittance-request will be made using the system
Remittance Out
The sending outlet or CRU will use the ‘REMITTANCE OUT’ function
to view the quantity and value for each stock item. When completed a
‘Remittance Out’ slip is printed by the sending outlet or CRU. This
process generates remittance out transactions and decreases the stock
unit at the outlet, or the CRU stock levels.
Remittance In
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 162
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
The requesting outlet will use the ‘REMITTANCE IN’ function to view
and confirm the quantity and value for each stock item to be taken in.
When this is completed a ‘Remittance In’ slip is printed by the requesting
outlet. This process generates remittance in transactions and increases the
stock unit’s levels.
Remittance Completion
The physical exchange of stock is accompanied by the signing of the
‘Remittance Out’ receipt by the requesting outlet. The sending outlet or
CRU keeps the signed receipt as proof of the transaction.
4.1.3.2.7 STOCK UNiT BALANCING
Stock unit balancing is the process of reconciling the user’s current stock
unit contents against the transactions completed and the opening stock
unit contents. Each stock unit must be balanced at the end of the Cash
Account week, At this point the stock unit is ‘rolled over’ to the next
Cash Account week.
In addition to this compulsory balancing, a stock unit may be balanced at
any time during the Cash Account week. Specifically the user will balance
the stock unit at the end of the duty period. A shared stock unit cannot
be balanced whilst it is still being used for sharing.
The system will produce a ‘Stock Unit Balance’ form consisting of
approximately 4 A4 size pages providing a summary of the clerk’s
activity
during the balance period. A copy of this form is also used as the office
balance form and this is the amalgamation of all counter balance forms in
a Cash Account week.
The Balancing Process
Although balancing will be a largely automatic process, the counter clerk:
must perform the following activities:
e Confirm all the stock and cash movements (transfers and remittances)
e Declare actual cash in hand
e Declare actual stock in hand
Declare Stock in Hand
The clerk will verify the actual physical stock unit contents for each stock
item. If there is any difference between the actual stock held and the
stock as maintained by the system, this will be an indication that errors
have occurred.
Print Stock in Hand Report
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 163
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
_DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
This facility will produce a printed report of all stock items within the
stock unit.
Declare Cash in Hand
The clerk will verify the actual physical cash in hand in the stock unit by
denomination, (including coins). If there is a difference between the total
maintained by the system, this will be an indication that errors have
occurred.
Daily Cash Locked Up
The system will ensure that the ‘Declare Cash in Hand’ function is used
at the end of every day for all stock units, The end of day function will
not be possible until this action is completed.
Produce Trial Balance
The clerk will complete a trial balance before completing a final balance,
enabling the rectification of errors prior to the stock unit balance period
being closed.
Produce Final Balance
This is the irreversible confirmation that the trial balance has been
accepted. It will close the stock unit balance period and allow the
detachment of the stock unit.
Declare Losses and Gains
The clerk will declare any loss or gain transactions manually during the
service process.
Clear Losses and Gains
The clerk may clear losses and gains to remove them from the office
balance upon resolution of any queries.
4.1.3.2.8 PRINT REPORTS AND CLIENT SUMMARIES
The office manager will print reports and client summaries required
using data extracted from the stock unit and user as well as by day, time
ard date. The following set of reports and summaries is representative of
the cutput which is currently: produced.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 164
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
DAILY REPORTS WEEKLY REPORTS OTHER REPORTS
e DNS Deposits e DNS Weekly e Milk Tokens
e DNS Withdrawals Summary (DNS 54) Reconciliation
e DNS Daily Summary » MVLs-V10 e MVLs
(DNS 56) e MVLs-V11 Reconciliation
¢ Girobank Deposits e MVis - V570
e Girobank Summary
Withdrawals © Pensions and
e Telephone Accounts Allowances
Paid e DSS Girocheques
e Pensions and Paid
Allowances Add Liste Redeemed Savings
e Local Schemes Stamps
© Cheques e Postal Orders Paid
© P884
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 165
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4.1.3.2.9 REVERSE A TRANSACTION
The clerk may reverse transactions that are reversible. Any reversal will
not result in transaction information being declared in the journal and
will insert additional compensating and correcting transactions.
All reversible transactions may be revers -d at any time during the Cash
Account week unless specifically prohibited, e.g., APS transactions
already notified r9 the client.
4.1.3.2.10 I CLIENT TKANSACTION CUT-OFFS
The clerk may declare by transaction type, on a client by client basis a
cut-off time. This will control client summary reporting.
4.1.3.2.11 END OF DAY
The end of day function will indicate a cut-off for all activities that occur
ona daily basis.
4.1.3.2.12 ROLL OVER
The final balance period for a stock unit in the Cash Account week will
be identified through the ‘roll-over’ function. The last set of balance
information for each stock unit at roll-over is used for producing the
office balance and the Cash Account.
4.1.3.3 OFFICE ADMINISTRATION
This section describes the office administration functions generally
completed by the office manager or deputy.
4.1.3.3.1 USER MAINTENANCE
Add User
This allows new users to be included within the system. The information
appertaining to each user will include :!,. Name, ID and privilege level.
Remove User
This allows the user to be removed from the system.
Modify User Details
This allows existing user’s details to be changed. The user will be
disabled whilst details are being modified.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D. DOC Page 166
FUJ00119561
FUJ00119561
Pathway ~~ Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4.1.3.3.2 STOCK UNIT MAINTENANCE
Add Stock Unit
This allows new stock units to be introduced into the system. Each stock
unit has a unique ID, and / or name and an access level.
Remove Stock Unit
This allows stock unit: to be removed o1 deleted from the system. A
stock unit cannot be removed if it is in use.
Modify Stock Unit ;
This allows a stock unit’s details, such as access levels, to be changed. It
can be suspended without deleting it from the system.
4.1.3.3.3 ATTACH/DETACH A STOCK UNIT
This allows a selected stock unit to be attached to a selected user at the
counter. This is similar to the counter administration function and is
provided here for convenience.
In the event of the unavailability of the counter clerk, e.g., due to illness,
the facility will be available to allow an authorised user to detach the
stock unit and reattach it to another user.
4.1.3.3.4 OFFICE CASH ACCOUNT
The Cash Account is a definitive summary of all of the business
transacted at the Post Office during the Cash Account week.
The production of the Cash Account can only happen after all activities
in that Cash Account week have been completed.
The Cash Account production process can therefore be carried out on
the data collected for one Cash Account week following balancing of the
stock units, whilst they are being used to serve customers in the next
Cash Account week.
4.1.3.4 OFFICE BALANCE (WEEKLY CASH BOOK)
The office balance is analogous to the weekly cash book used in sub-post
offices. For the purposes of this document the office balance and the
weekly cash book will be considered to be the same aid will be referred
to as the office balance.
The production of the office balance is a precursor to the production of
the Cash Account. In simple terms, the office balance is an
amalgamation
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 167
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
of all of the individual stock unit balances within the cash account week.
In order to produce the office balance all stock un.ts must have been
balanced and “rolled-over” to the next. cash account week.
INSTANT OFFICE SNAPSHOT
The system will provide an office level snapshot, at any time, of
transactions, cash and stock levels across all stock units. The same
facility will be available to provide an instant snapshot of the transactions
and contents of any single stock unit.
4.1.3.5 CASH ACCOUNT
The production of the Cash Account will be an automatic process
following the successful completion of the office balance. Unclaimed
Payments, Uncharged Receipts anid Error Notices will be derived and
added.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 165
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.1.3.6
4.1.3.7
4.1.3.7.1
4.1.3.8
END OF WEEK
The successful completion of the Cash. Account report will allow the
selection of an “end of week” function. This will “roll-over” the office
to next Cash Account week and make figures available to subsequent
processes such as Remuneration.
ACCOUNTING ADJUSTMENTS
This function will ailow an authorised user to apply adjustment
transactions as required for the office balance process.
TRANSACTION REVERSALS
A facility will be provided to allow the reversal of transactions from a
balanced or rolled-over stock unit balance period. The transaction
should not have been despatched (i.e. client cut-off) from the office.
The reversal must be carried out by the office manager: He will select
the stock unit balance period and browse the transaction journal in order
to find and select the transaction for reversal. A loss or gain transaction
may need to be generated to account for any cash (or other MoP)
involved in the transaction. The stock unit balance report and any client
summary will need to be re-printed to reflect the reversal.
If the transaction has already been despatched (i.e. client cut-off) from
the office then it is not reversible. The error will probably result in the
receipt of an error notice from the client.
Note
There is a distinction between a reversal for accounting corrections, such
as the loss of a foil or stub, and a reversal due to a transaction refund
(e.g. when a customer changes his mind)
OFFICE REPORTS
This allows the printing of office daily and weekly reports.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 169
FUJ00119561
FUJ00119561
Pathway ~ Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.1.3.9 MAINTAIN REFERENCE DATA
This facility will allow controlled modifications to be made to the
reference data to account for price changes, local products and so on.
Please note, these types of modifications are normally made centrally.
4.1.3.10 STOCK PRODUCT DATA
This function allows changes to be made to existing stock products. It
will be possible to:
e Modify stock product data such as the unit price. (Adjustment
transactions may be generated to account for revaliation’s of stock)
¢ Disable a stock product so that it is not available for sale.
e Enable a new version of a stock product and “freezing” the previous
version.
4.13.11 OTHER PRODUCT DATA
This function allows changes to be made to existing products. It will be
possible to: .
e Modify product data such as the default price.
¢ Disable a product so that it is not available for sale.
e Enable a new version of a product and “freezing” the previous
version.
4.13.12 CASH ACCOUNT TEMPORARY LINES
This function is used to “enable” those lines on the cash account which
are marked as temporary. This function will only be used when directed
by FAD Chesterfield. When a temporary line is enabled a corresponding
product will be available for “selling” at the counter.
4.13.13 LOCAL SCHEMES
P, oducts for local schemes are transacted at the counter. Daily and
weekly client reports mtist be generated for each local scheme. Local
schemes are reported in the payments, receipts, uncharged, or unclaimed
tables on the cash account.
This function will allow local schemes to be added, modified and
deleted.
4.1.3.14 AUTOMATED PRODUCTS
Printed: 22/05/96 COMMERCIAL IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 170
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
utomated products are reported in the cash account receipts and
payments tables. This function allows automated products to be added,
modified and deleted.
4.13.15 MAINTAIN OFFICE DATA
This facility will allow controlled modifications to bé made to the office
data for administrative purposes.
4.1.3.15.1 I SET TIME AND DATE
The time and date, (DD/MM/YY) will be mai..cained centrally and will be
transmitted to post offices by Riposte thus ensuring that they are
synchronised.
4.1.3.15.2 OFFICE DETAILS
This function will allow the modification of some office specific
information including office name and address.
4.1.3.15.3 CASH TARGETS
This function allows the specification of office targets for the daily cash
locked up. This is the equivalent of the existing ONCH form except that
the information is available by denomination
4.1.3.15.4 BALANCE/DAILY CASH BOOK PRINTING OPTIONS
This function allows the user to select which tables will be printed as part
of the office balance.
4.1.3.15.5 I CASH ACCOUNT DATES
The cash account calendar, including the cash account week numbers, is
published by The Post Office. However, it is necessary to allow some
flexibility such as a multi-week cash account for when the sub postmaster
goes on holiday and cannot balance his office until he returns.
4.1.3.15.6 I PREFERENCES
The preferences function will be used to allow some minor “tailoring” of
the system to su.c individual requirements.
4.1.3.16 TRAINING MODE
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 17!
FUJ00119561
FUJ00119561
Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
Pathway
For training purposes, EPOSS will provide a built-in training mode
which:
e Allows the serving of (imaginary) customers for all customer
transactions.
e Allows all operations used in accounting and balancing of a.stock unit.
e Is functionally indistinguishable from normal operation, except that
clear indication is permanently provided that training mode is in use.
e Records all counter operations and transactions.
e Can be used at any time by any user (including a live post office
environment).
e Excludes training transactions from the office accounting and
balancing process.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 172
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
e Allows the production of receipts and reports
The EPOSS application will provide an effective training mode through
the implementation of “training” stock units.
4.1.3.16.1 TRAINING STOCK UNIT
All stock units have a Type attribute. A normal stock unit has its Type
attribute set to “Normal”, but a training stock unit is one which whose
Type attribute is set to “Training”.
4.1.3.16.2 WORKING IN TRAINING MODE
To activate training mode, the user simply has to attach to a training
stock unit instead of a normal one. When this is done the system is
automatically in training mode.
4.1.3.16.3 EXITING TRAINING MODE
To deactivate training mode, the user just detaches from the training
stock unit.
4.1.3.16.4 CREATING TRAINING STOCK UNITS
The system will have a default set of training stock units on installation.
The number and contents of each training stock. can be tailored to suit
the individual office environment using the office administration
functions.
4.1.3.16.5 I INDICATING TRAINING MODE IS ACTIVE
Since the training mode operation is functionally identical to normal
operation a clear, permanent and unmissable indication will be provided
to ensure that the user is aware that training mode is active.
In training mode the screen background will be a different colour from
normal operation. For example, if normally the background is blue then
in training mode the background will be red. Also, the word
“TRAINING” will be permanently displayed in LARGE type inset in to
the background and any stock unit level reports will be marked
“TRAINING”.
4.1.3.16.6 TRAINING MODE COUNTER OPERATION
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 173
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
All counter functionality which involves the use of a stock unit will
continue to operate in the same way for a training stock. Exceptions to
this are those operations which involve other stock units, such as stock
transfers. Such functions will only operate between training stock units.
4.1.3.16.7. AND EXCLUDING TRAINING MODE TRANSACTIONS FROM
THE OFFICE ACCOUNTING BALANCING PROCESS
The office accounting, balancing and reporting process will automatically
detect and exclude training mode transactions.
Such data can be analysed to provide information about the use of
training mode within a post office.
4.1.3.16.8 I USING TRAINING DATA
Some transactions involve the use of centrally distributed data. For
example, BES uses payment authorisation data distributed by PAS via
TMS.
The use of centrally distributed test data for these transactions is useful
for testing and training. This data can be used in combination with a
training stock unit to provide a very effective training environment.
4.1.3.16.9 HOW TMS HANDLES TRAINING TRANSACTION DATA
Transaction data recorded during training mode will be marked as such
so that TMS can isolate it and handle it effectively. This data can be
analysed at TMS level to provide information about the use of training
mode within the post offices.
4.1.4 POCL INFRASTRUCTURE SERVICES
4.1.4.1 OFFICE PLATFORM SERVICE
This section describes the counter hardware infrastructure that will be
supplied by Pathway to meet the requirements of OPS and the required
application services (BES, APS, EPOSS ar: OBCS).
Each post office will have installed a set of PC based equipment
comprising a counter configuration per active counter and a back office
printer.
Two types of configuration will be provided :
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC. Page 174
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
e A standard configuration which will be suitable for the majority of
post offices.
e A mobile configuration which will be required in approximately 100
outlets.
Opportunities may arise in the period up to roll out to make changes to
the specific products proposed. There may be commercial or operational
advantages associated with a new produc: or model. Further dialogue
with BA/POCL may refine the requirements of OPS or the associated
applications services which will result in'a change.
Pathway wil! carefully consider any such changes and ensure that
functionally and risk are not adversely affected. Any changes will be
discussed with BA/POCL.
4.1.4.1.1 STANDARD CONFIGURATION
The standard configuration will comprise a PC mounted underneath the
counter together with a range of peripherals positioned on the counter
top. Each counter position will have its own set of data and power
cables which will be installed as unobtrusively as local conditions allow.
One counter PC will be nominated the gateway PC and will support the
ISDN card for connection to the BT installed ISDN outlet.
The back office printer will connect via a parallel cable to the most
convenient PC. A local area network will be installed in every post office
with three or more counters using C\T-5 UTP Ethernet and unmanaged
hubs.
All single counter post offices will have an exchangeable hard disk fitted
to facilitate the rapid exchange of system and application data if the PC
fails.
A separate back office configuration will be installed in those post offices
where there is an appropriate physical environment and the business
activities and workload require this additional IT infrastructure. It is
expected that this will be limited to Crown post offices. The list of
outlets is subject to agreement with POCL, together with any variation in
counter peripherals (e.g. fewer peripherals, larger monitor etc.).
4.1.4.1.2 OPS BASELINE DEFINITION
R560 recognised that technological change will occur during this
procurement and that DSS, POCL and Pathway would wish to take
advantage of any advances within the bounds of operational and
commercial obligations. In particular PC technology will change during
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 175
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/00L
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
the period from contract award to the start of roll-out in the areas of
processor speed and disc capacity.
In order that the OPS configuration at roll-out can be based on the most
suitable technology, Pathway will manage the introduction of a small
number of changes to the PC specification during the various integration
and testing phases which lead up to roll-out. These changes to the OPS
baseline prior to roll-out will be fully tested to ensure the operational
and functional obligations of Pathway are not compromised.
The target roll-out counter configuration will comprise :
Pentium 166Mhz PC running Windows NT client
Serial card
ISDN card (gateway PC only)
Colour Touch Screen (10 inch)
Keyboard
Magnetic Card Reader and Smart Card " eader
Barcode Reader
Counter Receipt and Slip printer
Smart Key reader (provided by APPU as required)
4.1.4.1.3 EQUIPMENT SUBSTITUTION
There will be a number of situations where OPS equipment will be
substituted from the baseline already declared to POCL or from the
above target roll-out configuration. This may result from new
functionality required by POCL, advantageous technological advances or
mutually agreed changes due to particular outlet circumstances.
Optional POCL requirements
One or more alternative data capture peripherals will be substituted for
the barcode reader if either or both of the optional data capture methods
required by POCL are confirmed. The optional methods requested by
POCL are :
© OCR / Barcode reading
e 2D barcode reading
[DN: It will be necessary for a final decision to be taken on the Release I
counter configuration by the date of agreement of this functional
specification. ]
Alternative products
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 176
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Following submission of the Counter Hardware Specification in January
1996 to the POCL Infrastructure team, Pathway have continued to assess
the benefits that alternative products would bring to BA/POCL. The
current Pathway proposal has been enhanced as shown below :
Mandatory Original Target roll-out Benefits
Item
Proposal configuration
Counter PC 100Mhz Counter I 166Mhz © To take advantage of
PC with 540Mb _ I Counter PC with latest PC technology
Hard Disc 1Gb Hard Disc Ie To improve the
operational efficiency of
Ops.
Monitor
9.5” colour 10” colour touch To increase the
touch monitor monitor viewable screen area
Counter
Printer
Epson TM-U375 I Ithaca Series 94 I e Faster printer will assist
counter printer printer counter transaction
times
¢ Internal power supply
minimises equipment
space requirements
Keyboard
LIFT-Key See keyboard © Space considerations
section may result in change to
keyboard
Optional Item
reader
OCR/Barcode I Optoline 3140 Caere 840 e Controller on PC card
minimises equipment
space requirements
4.1.4.1.4
Space Constraints
Pathway believes that there may be some outlets where the physical
counter space is so limited that a reduced footprint solution is required.
It is recognised that the full range of services will still be required but
some alternative methods of operation may be necessary. An approach
to address this may be to use a smaller compact keyboard and separate
card reader providing a reduced counter footprint and more options for
equipment placement.
MOBILE CONFIGURATION
A mobile configuration will be supplied to those outlets where physical
conditions or the nature of the service is not suitable for a standard, fixed
counter infrastructure. These will typically be satellite offices,
community offices and mobile offices. There will be less than 100 such
configurations.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC. Page 177
_ Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.1.4.1.5
A mobile configuration will be supplied where actual mobility is required
(e.g. the same equipment moving from site to site) or where mobility
within an outlet is regularly required.
Further discussion and agreement is required with POCL to define the
precise numbers and circumstances of each mobile configuration, and to
agree the services that will be required. This specification will have direct
bearing on the final configuration, although the principle of mobility is
understood and will be supported.
Target Mobile Configuration
Subject to a final specification, the target mobile configuration will be
based around :
Laptop PC
Slip printer (also used for receipting as required)
Magnetic stripe reader (with smart card reader if required)
Barcode reader (if required)
Housed in a robust carry-case
eooe eo
Network connection will either be made to a permanent ISDN line
installed in the outlet or via a GSM mobile phone. There are some areas
of the country where GSM coverage is not currently available. This will
need to be considered when agreeing the specification for any affected
outlets.
KEYBOARD
Pathway recognises the importance of providing a consistent and
ergonomically acceptable counter infrastructure, which meets the
operational needs of the user and is consistent with the physical
limitations of most post offices. The keyboard represents a key element
of this infrastructure, acting as a supporting device to the touch screen
and event activated counter system.
[Discussion and agreement is required on the selection of the keyboard, on
the use of colour, legend engravings and key positions.]
1. Proposed Keyboard
Printed: 22/05/96 COMMERCIAL-'N-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 178
FUJ00119561
FUJ00119561
Pathway ~ Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
Pathway recognises that for some outlets, principally the single counter
offices, the limited counter space will have an important influence on
final OPS equipment selection. Pathway also strongly supports the need
for a consistent OPS configuration in order that equipment support,
spares and logistics processes are kept to a minimum.
Accordingly Pathway now propose that the following small-footprint
keyboard should be used for all outlets :
Cherry ML4100
Dimensions (mm) 281.5 (I) x 131.5 (w) x 23.5 (h)
Number of keys 83 keys
(DN: If the oabove option is selected a separate card reader/encoder will
be provided as detailed below.}
Separate Magnetic/Smart Card reader encoder
ICL FCR20S
Dimensions 40mm (H) x 195mm (W) x 60mm (D)
Standards MCR - ISO 7810, 7811 1-4, 7813, 4909
SCR - ISO/IEC 7816 (T=0,T=1),
GFM2K, GFM4K
Programming Voltages Sv, 12.5v, 15v, 21v.
2. Alternative keyboard
Pathway’s original proposal was for the LIFT-Key keyboard which
provides an ergonomically attractive key layout with distinct alpha,
numeric and function/control key areas. Also included is an integrated
magnetic card and smart card reader.
LIFT-Key keyboard
A compact keyboard which provides the full functionality of a
standard 101-key PC keyboard while occupying half the counter
space. The keys are laid out in four distinct areas covering alpha
keys, a centrally placed numeric block, a set of function keys and a
set of cursor control and general keys.
Dimensions (mm) 280(width) x 240(depth) x 48 (height)
Number of keys 96
Key size Alpha = 15.4mm x 15.4mm
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 170
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
Numeric/Other = 18.3mm x 18.3mm
LIFT-Key Keyboard with Integral Magnetic Card reader / Smart
Card reader Encoder
The Magnetic Card reader and Smart Card reader are integrated
into the keyboard. The MCR is positioned across the top of the
keyboard providing a long swipe path for left or right handed
users. The SCR is positioned on the left hand side and uses a
Zero Insertion Force connector to minimise friction on the card
contacts.
4.1.4.1.6 FINAL OPS CONFIGURATION
There are important and largely fixed milests 1es and lead times
associated with the procurement of the vo’ me of equipment required
for OPS roll-out. Some product enhancements may also be necessary to
ensure the optimum OPS configuration is available meet the POCL
requirements.
Pathway seeks to expedite this process by reaching agreement
particular;ly concerning the optional functionality specified by POCL
(mainly OCR and 2D document reading), and in the equipment
proposals outlined above.
[DN: It will be necessary for a finai decision to be taken on the Release I
counter configuration by the target date of agreement of this functional
specification.]
(DN: It will be necessary for a final decision to be taken on the colour,
and any cosmetic aspects of the counter top peripherals, together with
keyboard layout and key engravings. These should be agreed by the target
date of agreement of this functional specification. ]
4.1.4.2 TMS
4.1.4.2.1 INTRODUCTION
The Transaction Management Service’ (TMS) occupies a central position
in the Pathway solution providing the interworking between the post
* Requirement 869 expands TMS to Transaction Monitoring System, but it is believed
that no difference in scope and purpose is intended.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 180
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.1.4.3
4.1.4.3.1
4.1.4.3.2
offices and Pathway’s central processing sites. The software which TMS
comprises runs on both the post office and the correspondence server
equipment, presenting interfaces to central services systems such as PAS,
CMS, IM, TIP, POCL HQ systems and the OPS, providing linkage and
message store and forward between them.
The fundamental role of the TMS is that of a reliable distributed
database for the OPS and the central processing systems.
COMMERCIAL ATTRIBUTES
Before detailing the functional capabilities thac the TMS will provide, it
is necessary to recognise several required commercial level attributes
which impinge on design and implementation:
DISCRETENESS
DSS/POCL require that TMS will be kept logically discrete from other
services such that, “in extremis”, the service could be separately
procured.
In particular there will be a clear and documented interface between the
central services and OPS program functions. These interfaces will
include:
© specification of any programming interface that exists
© specification of any shared data and data standards
© specification of any other protocols that exist to allow communication
between functions within the services
© specification of any other constraint that enables the interoperability
between services
SCALEABILITY
TMS will be scaleable to meet POCL’s business needs.
POCL are looking to re-engineer current client transactions and develop
new capabilities. This may involve considerable volumes of transactions
needing authorisation from a. POCL Client system or a central point in
POCL.
Pathway expects to meet this requirement by expanding the TMS
infrastructure and underlying network to bring in more resources to meet
any workload growth beyond that currently projected. Pathway. expects
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 181
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
to monitor traffic patterns and resource usage during operational trials
and early live use to adapt TMS resource deployment.
The general method of configuring in new POCL or POCL Client host
based systems is to use an Agent program to provide the linkage and
translation between the host and TMS Host API.
4.1.4.3.3 EXCLUSIVITY
DSS/POCL require that services which connect to and utilise TMS (or the
OPS) will oii!) be provided subject to the express agreement of
DSS/POCL. At one or more levels there will be a list of those computer
systems which are authorised to access TMS.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4D.DOC Page 182
FUJ00119561
FUJ00119561
.. Pathway Ref: PFS/PA/OOL
° DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4.1.5.4 FUNCTIONS TO BE SUPPORTED
4.1.5.4.1 BASIC TMS FACILITIES
4.1.5.4.1.1 CONNECTION
TMS will link into each instance of OPS <o allow the efficient transfer, in
both directions, of authorised data. Post office counter configurations in
multi-counter offices will be linked with Local Area Networks (LANs)
within the post office. Each post office configuration will be linked to an
ISDN Wide Area Network (WAN) using a basic rate card in the first or
only counter PC.
TMS will link to the post offices from the correspondence layer via ISDN
IP routers supporting primary rate connections.
A small minority of single counter post offices of a mobile variety will
use cellular telephony instead of ISDN.
TMS will provide links into other computer systems as required to
support DSS/POCL. These systems will include:
© systems operated on behalf of POCL’s Clients including PAS and CMS
e other POCL systems, for example TIP, IM and POCL HQ systems
e Pathway systems
These links will be through Agent programs interfacing to TMS through
multiple correspondence servers .
TMS will authenticate the identity of any computer system with which a
switched link is to be established (CHAP) and select and maintain
connection routes (OSPF, RIP).
TMS will produce reports detailing any attempt to establish’ a link which
is rejected. These reports will be available to DSS/POCL on request.
4.1.5.4.1.2 COMMUNICATIONS ACCESS SUPPORT
TMS will support ISDN communications between the Correspondence
layer and the post offices.
ISDN channel use will be optimised by facilities to force call termination,
explicitly open a call, vary transfer increments and flow control and retry
alternative destination addresses on final failure.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4E.DOC Page 183
FUJ00119561
FUJ00119561
Pathway Ref: PES/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
Between TMS nodes it is expected that UDP will ve used. Multiple
frame transfers will be presented at the destination in original sequence.
Multicast local area addressing will be supported.
There will be measures to avoid flooding gateways on call establishment.
4.1.5.4.1.3. INTERFACE SUPPORT
4.1.5.4.1.3.1 DSS INTERFACES
TMS will support interfaces:
e with PAS/CMS to/from outlets (via Agent programs)
¢ with OBCS Hosi to/from outlets
© between.outlets for “foreign office” pro -ssing
415.41.3.2 POCL INTERFACES
TMS will support interfaces:
with [M to/from outlets
with TIP to/from outlets
with POCL Clients
with POCL HQ (Farnborough Data Polling Centre)
between outlets (potentially for messaging)
with the OPS
415.4.1.33 PATHWAY INTERFACES
Pathway MIS
Help Desks
Systems Management
Network Management
4.1.5.4.1.4 DATA TRANSFER ATTRIBUTES
TMS will ensure that any cata transfer can be shown to be complete,
secure accurate and robust.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4E.DOC Page 184
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version:
Date:
TMS will use data replication and synchronisation techniques based on
marker exchange, Cyclic Redundancy Checks (CRCs), Digital Signatures
and Encryption as applicable to ensure that data is complete, secure,
accurate and robust.
4.1.5.4.1.4.1 RUGGEDNESS OF DISTRIBUTED DATABASE
When a session of transactions, or a transaction requiring transaction
level commitment, is settled at a counter position details will be written
to the OPS journal.
This information will be reliably replicated to all other counter position
PCs in that post office, to a remote server within TMS and from that
server to at least two other servers, of which one will be geographically
removed from the other two.
Data transfers may originate from an individual counter PC (e.g. a bill
payment) and will be replicated through TMS, or from a Central
Services system (e.g. PAS) and be replicated through TMS to transfer
data to OPS in a like manner.
Techniques will be used to maintain these replicas in step both in normal
operation and in recovery situations:
grouping of post office and correspondence server nodes
message numbering
marker (message high and low water marks) exchange
message transfers to equalise water marks
4.1.5.4142 DATAINTEGRITY
Three techniques will be used to ensure data integrity within the OPS
and as part of data/message transfer across TMS:
¢ CRCs will be calculated for all journal records, including software and
reference data
e Digital Signatures will be used for all data where assurance of content
and source are required (e.g. benefit payment authorisation records)
« Access to the journal only in read and append methods
All journal records will have a CRC calculated and applied when they are
initially written to the journal and this CRC will be recomputed and
checked whenever the record is read. Any failure of a CRC check will
cause the journal to be recovered in an efficient manner.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4E.DOC Page 185
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
When authentication of the origin and content of data is important (e.g.
for benefit payment authorisations), a digital signature will be applied to
the data prior to transmission and then checked upon receipt. Digital
signature techniques will be available for use both outbound to the OPS
and inbound.
Detection of tampering or corruption though CRC or Digital Signature
failure, will be logged for subsequent investigation.
All transfers to the journal either at the correspondence layer or in OPS
will be written by appending a record (often a modified version of one
read from the journal). These journal messages will include all the data
required to identify the transfer uniquely. Data, once written to the
journal, will never be altered (except through the secure processes of the
archive).
4.1.54.1.43 DATAPRIVACY
Selective symmetric “codebook” encryption of data stored on disk will be
used to provide privacy for certain data items when stored on disk in the
post office.
Failure of the codebook logic self-test or subsequent access failure of an
apparently mis-deciphered record will be detected and logged for
subsequent investigation.
4.1.5.4.1.4.4 DATACURRENCY
e Application message transfers
As seen from a counter application or a TMS Agent application, it will be
possible to be certain, at some level, that data has been positively
acknowledged as received by TMS. In addition it will be possible, at
some level, to be certain that data has been positively acknowledged as
received by a peer application also attached to TMS.
These assured outcome transfers will be used to support foreign
payment, agent and systems management record access.
° Message store
TMS and OPS will automatically replicate the transaction data which is
created at the OPS from the post offices to the correspondence layer.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4E.DOC Page 186
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
The data will then be available for processing by the relevant client
system which may include Pathway, DSS/POCL or POCL client systems.
The “keep awake” replication period between OPS and TMS will be
configurable as required by the urgency of the transaction data and the
general levels of traffic from the post office. Data replication will also
take advantage of connections that are established between TMS and
OPS for other purposes, e.g. a card or payment stop message, foreign
payment.
A particular limiting case is the single counter office where replication
will be facilitated periodically. The single counter office will be equipped
with a removable hard disk so that if the counter fails, unreplicated data
will be both preserved and capable of transfe. to a new system unit. In
addition TMS will cache such data accumulated since the last replication
in main store so that, in the event the removable hard disk fails, the
cached data will be replicated so the correspondence layer before halting
the OPS.
It.is a. key applications requirement that end-of-day procedures are
supported by ensuring that end of day markers are conveyed to the
correspondence layer to enable POCL Client processing to proceed on
consistent datasets.
EPOSS will initiate a connection to replicate the final POCL end-of-day
balances and this process will also force the replication of any
outstanding transactions that have not previously been sent to TMS.
Data transfers will be capable of being despatched as:
e Immediate
e Background/trickle feed
© Time deferred
4.1.5.4.1.5 I DATA TRANSFER OPERATIONS
TMS will provide data file collection and data file delivery services,
where a data file is defined as any set of electronic data. It should be
noted that the data aggregate paradigm used for transfer within Riposte
is the message aind it is this that is sed to map data aggregates of the size
required.
41.5.4.1.5.1 FILES AND RECORDS
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4E. DOC Page [S7
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
TMS will support the distribution. and collection of both file and record
level data to and from the OPS. This will be achieved by both by
automatic replication of records extracted from files from the OPS in a
post office to a TMS server and the reverse, and by explicit file level
transfers. Large data transfers spanning transmission frames will be
capable of being delivered in the same order as sent.
4.1.5.4.1.5.2 DEFINITION OF SCURCES AND SINKS
This will be implemented by defining the group and node structure and
by the operation of TMS interfaces that allow the calling p.ogram to seé
the correspondence servers as a single virtual correspondence server.
(The “wholesale broker”). Agent programs will transfer data to and from
groups in a group scatter-gather manner. Dats transfers to/from attached
computer systems will be controlled by Pathway operations and by the
facilities provided by the Agents.
At the same program level there will be an API which will allow Agent
programs to address one or more specified groups , for the purpose of
transfers in both directions, enabling full concurrency in both directions.
It will be possible to for Agents to transfer data to all the groups specified
in a call, with the data being held once per correspondence server (not
once per group).
TMS will provide a facility to allow programs at the counter to make
logical access to other “foreign” office counters for the purpose of
retrieving payment authorisation records from those counters. (Whether
this access is achieved by physical access to the TMS replicas of those
counter journals or to the foreign office replicas is not specified provided
required updates are reflected in all replicas in a timely manner.)
4.154153 FILE OPERATIONS
TMS will support the transfer of file level aggregates between two or
more computer systems attached to TMS.
@ A file distribution function will be responsible for transfer, monitoring
and retry of file level aggregates, typically at nights and weekends
© TMS will support this function in relation to
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4E. DOC Page 188
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
* triggering of transfers
* reporting of failures and retry of transfers
* identifying the population of systems connected to TMS
© TMS will include the file processing capabilities described below.
4.1.5.4.1.5.4 I FILE PROCESSING
Data file processing will be provided by the TMS Agents. These will
perform specific functions in association with individual host systems.
Agents will be built using generic modules for:
e File acquisition from client systems and file or record creation for
distribution to TMS (such acquisition may also be in the form of
transactional transfers)
e Client processing of data :o/from host systems
The TMS Agents will be customised for each specific host system link
and will provide the required conventional file processing facilities:
* validation of data files
* concatenation and merging of files
* generating many data filcs from one data file
* reformatting the contents ofa data file
* generating control totals
* reconciliation of control totals
* producing reports, financial and other summaries
41541.5.5 DATA TRANSFER INITIATION
Data transfers will be initiated by:
© Operator action - This will be the normal operational activity in
managing the data transfer from Pathway host systems to TMS using
workload scheduling, or the normal actions of the counter clerk in
carrying out transactions on OPS. Once a datafile has been passed to
TMS or a counter transaction has been committed within OPS the
collection/delivery of this data will be automatic.
e Time - The OPS applications will have access to interfaces that support
real and delayed time initiation of activities. The TMS Agents will also
Printed: 22/05/96 COMMERCIAL. !1N-CONFIDENCE
22/
C:\FINALPRN\PFISCT4E.DOC Page 189
Pathway
FUJ00119561
FUJ00119561
Ret: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
415.4.1.5.6
445.4157
use similar techniques. The “keep awake” time interval for data
replications between OPS and TMS will be handled as described above.
e External message - The requirement for an attached computer system
to initiate a data file collection or delivery will be met by the
functionality specified within the relevant TMS Agent in conjunction
with thai of the file distribution function.
DATA TRANSFER RETRY
TMS will effect a form of retry through marker exchange and replica
maintenance.
The end to end recovery facilities available for data transfer between
TMS and an attached computer system will depend on the method of
connection and the protocols and file transfer standards that are used
between it and the file distribution function or TMS Agent concerned
and are fundamentally the responsibility of these, not of TMS. These
will be agreed between Pathway and DSS/POCL and POCL clients as part
ot the specifications for connecting attached computer systems.
BROADCAST AND MESSAGING OPERATIONS
Using TMS and OPS it will be possible to broadcast short mess.iges to all
or a subset of outlets. A message length of up to 2Kb will be supported.
The message should be brought to the attention of staff working in the
outlet at the earliest practical opportunity. It should be possible to
produce a hard copy of the message within the outlet.
The message will be input into an application running at the
correspondence layer and will be replicated to post offices as required.
At the local post office each counter position will access these messages
and selectively open and view the message. Reading a message will be
recorded in the journal.
The user will be prompted that a message is outstanding by an indicator
on the top of.their screen. On selecting the appropriate icon the user
will be presented with a list of messages with an indicator showing their
status (read or unread). The message will be capable of being printed on
the back office printer.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4E.DOC Page 190.
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
[DN: The process by which such broadcast messages are to be prepared,
authorised and admitted to the system is to be agreed.]}
[DN: The means by which messages might be transferred between two
attached computer systems, including any two instances of the OPS,
beyond normal messages which carry transactions and foreign encashment
exchanges, requires discussion and agreement.]
4.15.4.1.5.° LIBRARY TYPE FILE ACCESS
Using TMS and OPS it should be possible for staff working in the outlets
to gain access to electronically held information such as is currently
published in ‘Counter News’ and the operations manuals.
A general facility which will enable these and other documents to be
viewed locally will be provided. Documents will be supplied in an
agreed format (e.g. HTML, RTF/Microsoft Word). They will be
distributed together with an updated index of current documents using
Systems Management facilities. Access to these documents will be via an
application from the user’s desktop.
[DN: Pathway would like to discuss alternative techniques for accessing
these documents.]}
4.1.5.4.1.6 © REMOTE OPERATION SUPPORT
TMS will support remote access to OPS restricting access to specifically
authorised users.
Users in post offices may log-on only to the OPS in their local post office.
Any access to data or services outside of the local post office will be
through the relevant counter application.
4.1.5.4.1.7 I AUDIT FACILITIES
A full audit trail of all TMS activity will be maintained.
The audit trail comprises the correspondence server level journal records
accessed through an Audit Agent.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4E. DOC Page 191
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
The journal records will be archived by removing replicas at the
correspondence layer (and removing all replicas ur old records at the
post office layer) and transferring the archive journal records to
exchangeable optical media. These volumes will be accessible by the
Audit Agent in the normal manner although retrieval will take account of
accessing records on off-line media
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4E.DOC Page 192
FUJ00119561
FUJ00119561
; Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4.1.5.5 DELIVERABLES
4.1.5.5.1 DOCUMENTATION
4.1.5.5.1.1 TECHNICAL DOCUMENTATION
Pathway will provide technical Cocumentation for TMS suitable to allow
DSS/POCL to procure applications which will utilise TMS. These
procurements will not necessarily be from Pathway. All changes to the
documentation will be passed to DSS/POCL for agreement.
This documentation will include TMS architectural and subsystem
descriptions including the interfaces used by Agent programs and
equipment technical specifications.
49.1.5.5.1.2 INTERFACE DOCUMENTATION
Detailed technical documentation of the interfaces including APIs from
TMS to PAS, CMS, OPS and all attachable computer systems will be
produced and maintained. In the event of changes to any interface to
TMS, this will -be notified to and passed to DSS/POCL for agreement in
advance, with updates to the technical documentation being provided
within ten working days of the change being implemented.
4.1.5.5.1.3. PERFORMANCE REQUIREMENTS
Internal performance requirements of any subsystem will be provided if
it is re-tendered. The requirements in respect of TMS will be in terms
of:
Hours of operation of TMS
e Response time required between TMS and
* OPS
* Agents (including those for PAS and CMS)
e Number of outages of TMS, identifying types of outage monitored
Availability of TMS.
4.1.5.5.1.4 REPORTS
TMS will maintain measurements of actual performance and fault
tolerance in relation to interfaces with subsystems.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4E. DOC Page 193
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
@ hours of operation of TMS
© response times at the interface with:
* OPS
* Agents (including those for PAS and CMS)
e@ Number of outages identifying tvpes of outage to include classes of
transfer which have failed
e Availability of TMS
4.1.5.6 TIP
4.1.5.6.1 OVERVIEW
This section describes the interface between TMS and TIP in terms of an
intermediate system known as the TTS host (TIP to TMS System) and
the TTS agent. The general function of TTS is to receive files of data
from TIP and return files of data to TIP. The initial format and contents
of the files has been derived from the PIRBPS.
The following diagram shows the placement of TTS within the overall
architecture:
TIP
pata Fite
— ry TTS Host
I Oracle? todata rite I TTS receives data from TMS via the TTS
Data File tq Oracte7 agent, processes it and passes it on to
TTS Host I I I TIP. Similarly, TTS receives data
I [ Oracle? II I directly from TIP, processes it and passes
I
t
it on to TMS via the TTS agent.
Journal to/Oracle7_ Ts Agent
The TTS agent is used to move data
. [TTS Agent’: between TMS and TTS. One
I Oractor tofJournat - component of it extracts TIP-bound data
out of TMS into TTS. Another
y TMS component of the agent imports TIP-
es. derived data from TTS into TMS.
4.1.5.6.2 TIP DATA
TIP data bound for TMS will be transferred on a daily basis, although in
some circumstances theré will be more frequent transmissions. The data
is categorised as: .
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4E.DOC Page 194
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
© Reference data about outlets
e Reference data for TMS, IM, APS and EPOSS operation
« Error Notices
¢ Messages and/or files for outlets
TMS data bound for TIP will be transmitted daily. The data is broadly
categorised as:
¢ Outlet transaction, accounting and other summary data for POCL.
This will include the individual bill payment data associated with
POCL Clients
(DN: Pathway believes there is an urgent ried to deal with the
competitive threat from Cashstop. This could addressed by providing
autoinated support to all paper bill payments and extending TIP to
these Clients.]
e Outlet transaction and summury data passed to clients
e Authorisations and exceptions bound for clients
4.1.5.6.3 TTS HOST OPERATION
Data from TIP Data for TIP
The TTS host will receive data The TTS host will receive data
from TIP in the form of files of from TMS in the form of Oracle7
data records on a daily basis. The I database tables on a daily basis.
physical format of this file will be I The TTS Export application is an
agreed with POCL. The TTS Oracle7 application which will
Import application is an Oracle7 read the Oracle7 tables and will
application which will read, transform these into data files in
process and transform the TIP data I the form expected by TIP.
files into Oracle7 database tables.
4.1.5.6.4 TTS AGENT OPERATION
Data from TIP Data for TIP
The TTS agent will read the TIP The TTS agent will read the TMS
data held in Oracle7 database journal data into Oracle7 database
records and write this into journal I tables as expected by the TTS
data records in the format Export application.
expected by TMS.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4E.DOC
Page 195
Pathway
Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4.1.5.6.5
4.1.5.7
41.S.7.1
GENERAL FILE FORMAT
The structure of files sent and received by TIP is generalised as follows:
File identification record
Section start/identification record
Subsection start/identification record
Actual data records
Subsection end/summary record
Section ‘trailer >
Section header
Subsection héader
Data record
Subsection trailer.
Section trailer
Data file trailer
Section end/summary record
File summary record
Note: There can be multiple sections within the file, multiple subsections
within a section, and multiple data records.
The actual structure of each type of file transferred is derived from
information contained in PIRBPS and is subject to change. As reflected
by PIRBPS, TIP is not sufficiently progressed in its implementation to
allow a definitive specification of the data it sends and receives. Similarly,
the content of the data files is equally dependent on the implementation
of EPOSS and the outlet applications.
Given this interdependency, the data file definitions will be derived using
an iterative process which takes into account the ongoing specification of
TIP, TMS and EPOSS.
INVENTORY MANAGEMENT
[DN: This section should be seen as indicative of facilities that might be
offered if support for IM interfaces is reintroduced into R831.]
OVERVIEW
This section describes the interface between TMS and IMS in terms of an
intermediate system known as the ITS host (IMS to TMS System) and the
ITS agent. The general function of ITS is to handle purchase orders and
confirmations, consignment enquiries and responses in an online fashion
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4E.DOC Page 196
FUJ00119561
FUJ00119561
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/8/96
to IMS. In addition to online operation, ITS will transfer files of data
(eg outlets stock takes) between IMS and TMS. The initial format and
contents of the data transferred has been derived from the POCL
Interfaces Requirements BA/POCL System document.
The following diagram shows the placement of ITS within the overall
architecture:
IMs
ITS Host
ITS receives data from TMS via the ITS
agent, processes it and passes it on to
IMS. Similarly, ITS receives data
directly from IMS, processes it and
ITS Host passes it on to TMS via the ITS agent.
ITS Agent
The ITS agent is used to move data
v between TMS and ITS. One component
ITS Agent of it extracts IMS-bound data out of
y ™s I TMS into ITS. Another component of
—vournat the agent imports IMS-derived data from
ITS into TMS.
4.1.5.7.2 IMS DATA
4.1.5.7.3 TMS DATA BOUND FOR IMS
Outlet purchase order
Order/consignment
enquiry
Consignment receipt
Consignment return
Inventory Count
Online request for inventory items
originating at the outlet. Results ina
purchase order confirmation.
Online enquiry abour a purchase order or
consignment.
Notification of a consignment received at
outlet. This is transmitted by the outlet on
receipt.
Notification of a consignment returned from
outlet. This is transmitted by the outlet on
dispatch.
Originates at the outlet as a stock and cash
Printed: 22/05/96
C:\FINALPRN\PFISCT4E.DOC
COMMERCIAL-IN-CONFIDENCE
Page 197
C:\FINALPRN\PFISCT4E.DOG
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
declaration process.
4.1.5.7.4 IMS DATA BOUND FOR TMS
. Purchase order Online response to the outlet’s purchase
confirmation order.
Order/consignment Online response to an enquiry about an
enquiry response existing order/consignment.
Inventory Adjustments — Information supplied by IMS to the outlet for
correction purposes.
Consignment advice Information supplied by IMS to the outlet
about the status of a consignment
4.1.5.7.5 ITS HOST OPERATION
Data for IMS. Data from IMS
The ITS host will receive data The ITS host will receive data
from TMS in the form of Oracle7 I from IMS in the form of files of
database tables. The ITS Export data records. The physical format
application (an Oracle7 of these files will be agreed with
application) will read the Oracle? I POCL. The ITS Import
tables and will transform these application (an Oracle7
into the data format expected by application) will read, process and
IMS. transform the IMS data files into
Oracle7 database tables.
4.1.5.7.6 ITS AGENT OPERATION
Data for IMS Data from IMS
The ITS agent will read the TMS Ir will read the IMS data held in
journal data into Oracle7 database I Oracle7 database records and
tables as expected by the ITS write this into journal data records
Export application. in the format expected by TMS.
[DN: Autonomous stock management by the ITS Agent to handle stock
reorder may be considered.]
4.1.5.7.7 ONLINE OPERATION
The diagram below shows the general data flows for online operations.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
Page 198
FUJ00119561
FUJ00119561
Pathway
DSS/POCL Functional Specification
Ref:
Date:
Version:
FUJ00119561
FUJ00119561
PFS/PA/O01
3.0
22/5/96
Outlet
a NN
1. Outet Request 6.1MS Respons
aN
‘Journal
TINS}
os
SATS "Agent = ITS Agent:
I
5.IMS Response
ITS Host
=
4.1m Response
~Laws
ITS Host
2. Outlet Request
Purchase Order and Confirmation
wa
aun
Consignment Enquiry and Response
1. The outlet transmits a consignment enquiry record to TMS.
. The outlet transmits a purchase order (a set of records) to TMS.
. The ITS agent picks up the records and sends them to the ITS host.
. The ITS host sends the records to IMS.
. IMS responds by sending an order confirmation to the ITS host.
. The ITS host sends the confirmation to the TMS agent.
. TMS transmits the confirmation to the outlet,
2. The ITS agent picks up the record and sends it to the ITS host.
3. The ITS host sends the request to IMS.
4. IMS responds by sending an enquiry response to the ITS host.
5. The ITS host sends the response to the TMS agent,
6. TMS transmits the response zo the outlet.
Printed: 22/05/96
C:\FINALPRN\PFISCT4E.DOC
COMMERCIAL-IN-CONFIDENCE
Page 199
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.1.5.7.8 GENERAL DATA FILE STRUCTURE
The structure of files sent and received by IMS can be generalised as
follows:
File identification record
Section start/identification record
Subsection start/identification record
Actual data records
Subsection end/summary record
Section trailer Section end/summary record
Section header
Subsection header
Data record
Subsection trailer
Section trailer
Data file trailer
File summary record
Note: There can be multiple sections within the file, multiple subsections
within a section, and multiple data records.
The actual structure of each type of file transterred is derived from
information contained in PIRBPS and is subject to change. As reflected
by PIRBPS, IMS is not sufficiently progressed in its implementation to
allow a definitive specification of the data it sends and receives. Similarly,
the content of the data files is equally dependent on the implementation
of EPOSS and the outlet applications.
Given this interdependency, the data file definitions will be derived using
an iterative process which takes into account the ongoing specification of
IMS, TMS and EPOSS.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4E.DOC Page 20
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.2 POCL CONTINGENCY SERVICE
4.2.1 INTRODUCTION
This section outlines the contingency arrangements in place for all BES,
OBCS (if selected) EPOSS and APS transactions handled at the post
office counter.
The following failures may affect the post office counter:
e Magnetic card reader failure :
e Bar-code reader failure (or OCR reader failure as appropriate if this
option is selected)
¢ Counter printer failure
e Weigh scale failure
e Back Office printer failure
¢ Keyboard failure
e Touch screen failure
© PC failure - single counter office
e PC failure - multi-counter office
e Network failure - ISDN connection
e Site-related failure
In addition, where failure affects communication from TMS to the post
office, contingency arrangements are in place to effect changes to the
current transaction data held by the office.
Prior to notifying the SIS Help Desk of any system failure, the clerk will
be required to consult a simple ‘check list’? which will be provided,
highlighting all of the obvious faults which can be corrected by the clerk,
for example; cables attached. .
Failure to resolve the problem within the post office will be reported to
the OPS Help Desk immediately by the clerk. In all instances,
contingency arrangements will be invoked at the discretion of the post
office manager or the nominated deputy.
The following text assumes all checks have been completed by the clerk,
the cards and documentation are in good repair and the hardware is
genuinely at fault.
Where contingency has been invoked, e.g., manual keying of account or
NINO detail, or the manual completion of a receipt, this will be
recorded by the system for audit purposes.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
€:\FINALPRN\PFISCT4F.DOC Page 201
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4.2.2 MAGNETIC CARD READER FAILURE
4.2.2.1 BES
Card reader failure may arise when ‘swiping’ benefit cards in respect of:
e Receipt of batches of cards into the post office (See also Bar-code
reader failure)
Collection and activation of card by customer
Benefit encashments using cards
Duplicate receipt requests
Change of nominated post office
4.2.2.1.1 CONTINGENCY ARRANGEMENTS
Receipt Of Batches Of Cards Into The Post Office
The.clerk will key details of the PAN for all cards received within the
batch. However, whenever possible, the card reconciliation function
should be left until the failure has been rectified.
Collection And Activation Of Card By Customer
The clerk will key details of the PAN and card issue number in order to
activate the card.
Benefit Encashment Using Card
e Multi Counter Office
If possible, refer the customer to a.iother counter position, or proceed as
for -
e Single Counter Office
The clerk will key details of the PAN and the card issue number.
Duplicate Receipt Request / Change Of Nominated Post Office
The clerk will key the PAN and card issue number in order to access the
screen required to complete the transaction.
4.2.2.2 OBCS
OBCS is unaffected by card reader faih:re.
4.2.2.3 EPOSS
Card reader failure may arise when magnetic cards are ‘swiped’ in respect
of:
e The capture of guarantee card details
¢ The acceptance of Credit / Debit cards as MoP
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 202
FUJ00119561
FUJ00119561
I
Pathway Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4.2.2.3.1 CONTINGENCY ARRANGEMENTS
The clerk will key the card details into the system and continue the
transaction.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 20.3
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4.2.2.4 APS
Card read failure may arise when magnetic cards and smart cards / keys
are presented.
4.2,.2.4.1 CONTINGENCY ARRANGEMENTS
e Multi Counter Office
If possible, refer the customer to another counter position, or proceed as
for-
e Single Counter Office
Automated Payment Using Magnetic Card
The clerk will select the ‘AUTOMATED PAYMENT (MAGNETIC
CARD) option from the ‘Serve Customer’ menu and key details of the
card number in order to access thé screen r-quired to complete the
transaction. The client identity displayed on the screen will provide a
check that the card details have been correctly keyed. The suggested
amount payable will not be displayed but the card will be embossed with
this information providing a guideline to the clerk.
Automated Payment Using Smart Card / Key
There are no contingency arrangements available for failure of smart
cards / keys or their readers. Hence, during periods of failure, such
transactions cannot be completed.
4.2.3 BAR-CODE / OCR READER FAILURE
4.2.3.1 BES
Bar-code / OCR reader failure may arise when reading bar-code
information from:
e Batch details of cards received into the post office (see also Magnetic
card reader failure)
e PUN details
4.23.11 CONTINGENCY ARRANGEMENTS
Batch Details Of Cards Received Into The Post Office
The clerk will key bar-code details from the batch. However, wherever
possible, the card reconciliation function should be left until the failure
has been rectified.
PUN Details
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 204
Pathway
DSS/POCL Functional Specification
Ref:
Version:
Date:
FUJ00119561
FUJ00119561
PFS/PA/OOL
3.0
22/5/96
The clerk will key bar-code details from the PUN.
Printed: 22/05/96
C:\FINALPRN\PFISCT4F.DOC
COMMERCIAL-!N-CONFIDENCE
Page 205
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.2.3.2 OBCS
Bar-code reader failure may arise when reading bar-codes during:
¢ Receipt of order books in post office
¢ Collection of order book by customer
¢ Benefit encashment using foil
4.2.3.2.1 CONTINGENCY ARRANGEMENTS
Receipt Of Urder Books Into The Post Office
The clerk will key bar-code details for all order books received within the
batch. However, wherever possible, the order book receipt function
should be left until the failure has been rectified.
Collection Of Order Book By Customer / Benefit Encashment Using
Foil
e Multi Counter Office
If possible, refer the customer to another counter position, or proceed as
for -
e Single Counter Office
The clerk will key bar-code details from the order book. in order to
access the screen required to complete the transaction.
4.2.3.3 EPOSS
EPOSS is unaffected by bar-code reader failure.
4.2.3.4 APS
APS transactions involving the reading of bar-code / OCR information,
for example; telephone bills and Transcash documentation, may result in
bar-code reader failure.
4.2.3.4.1 CONTINGENCY ARRANGEMENTS
The clerk will key details of the bar-code / CCR information in order
that the appropriate screen may be accessed to complete a customer
transaction, or to capture the information for reporting purposes.
4.2.4 COUNTER PRINTER FAILURE
4.2.4.1 BES
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:A\FINALPRN\PFISCT4F.DOC Page 206
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0.
Date: 22/5/96
The counter printer may fail to print either ‘tally roll’ receipts or
individual ‘slip’ receipts. BES transactions require the printing of
individual ‘slip’ receipts for:
e Home and foreign encashments made by the beneficiary or an
alternative payee requiring the provision of a standard receipt
e Casual or permanent agent encashments requiring the printing of
detail onto the mandate presented by the customer
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 207
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
e Duplicate receipts requested for any encashme.it
e Card Impounds
4.2.4.1.1 CONTINGENCY ARRANGEMENTS
e Multi Counter Office
If possible, refer the customer to another counter position, or proceed as
for -
© Single Counter Office
The clerk will clerically prepare a manual receipt (pre-printed with
standard legal statements provided on the printer receipt) with all
encashment details, or card details if impounded, together with the
encashment reference. If a mandate is presented in respeci of casual /
permanent agent encashments, this is completed clerically by the clerk.
The information could be taken ‘rom the card using an imprinter if held
in the post office.
4.2.4.2 OBCS
~ OBCS is unaffected by counter printer failure.
4.2.4.3 EPOSS / APS
The counter printer may fail to print either ‘tally roll’ receipts or
individual ‘slip’ receipts. EPOSS / APS transactions require the printing
of ‘tally roll’ receipts.
4.2.4.3.1 CONTINGENCY ARRANGEMENTS
The clerk will prepare a receipt using the card and an imprinter with the
clerical addition of payment details and the transaction reference
displayed on the screen.
4.2.5 ELECTRONIC WEIGH SCALE FAILURE
4.2.5.1 BES, OBCS, APS
These services are unaffected by electronic weigh scale failure.
4.2.5.2 EPOSS
Electronic weigh scale failure will only affect Inward / International Mail
transactions within the EPOSS service.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 208
FUJ00119561
FUJ00119561
I
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.2.5.2.1 CONTINGENCY ARRANGEMENTS
e Multi Counter Office
If possible, refer the customer to another counter position, or proceed as
for-
e Single Counter Office
The clerk will obtain the weight of the package using mechanical weigh
scales and input this weight intc the system.
Printed: 22/05/96 COMMERCIAL IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC. Page 209
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96 I
i
\
4.2.5.3 BACK OFFICE PRINTER FAILURE
The failure of the Back Office printer does not affect transactions.
handled at the counter. All counter services will proceed as normal.
4.2.5.3.1 CONTINGENCY ARRANGEMENTS
End of day / week / month activities requiring the printing of reports,
e.g., client summaries, balance reports and the Cash Account, will be
suspended until the printer is repaired.
4.2.6 KEYBOARD FAILURE
The keyboard is used to enter account numbers, reference numbers or
value where this information cannet be collected using the card or bar-
code readers. All transaction selections and system operations are
replicated on the touch screen.
4.2.6.1 BES, OBCS, EPOSS, APS
The following transactions are affected by keyvoard failure:
e BES transactions requiring the manual keying of card detail
¢ OBCS transactions requiring the manual keying of order book / foil
detail
e EPOSS / APS transactions requiring the manual keying of account/
reference number or value
4.2.6.1.1 CONTINGENCY ARRANGEMENTS
e Multi Counter Offices
If possible, refer the customer to another counter position, or proceed as
for:
© Single Counter Offices
Transactions requiring the manual entry of account numbers, references
o. values cannot proceed.
4.2.7 TOUCH SCREEN FAILURE
All touch screen functions are replicated on the keyboard. All counter
transactions can therefore proceed using the keyboard to select functions
and services.
4.2.8 PC FAILURE - SINGLE COUNTER OFFICE
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F. DOC Page 210
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1L
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
(‘PC’ refers to the PC itself plus the internal cards and monitor)
4.2.8.1 BES
The following transactions are affected by PC failure in a single counter
office:
© Receipt of batch of cards in post office
¢ Collection and Activation of card by customer
e Benefit encashment using card
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 2:1
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96 '
e Duplicate receipt request
e Change of nominated post office
4.2.8.1.1 CONTINGENCY ARRANGEMENTS
Receipt Of Batch Of Cards In Post Office
The card receipt and reconciliation func.ions will be left until the failure
has been rectified.
Collection And Activation Of Card By Customer
The customer will be requested to return when the fault has been
rectified.
Benefit Encashment Using Card
The clerk will telephone the PAS Help Desk and advise the customer’s
NINO and the card issue number. The PAS Help Desk acts as a ‘stand
in’ post office with access to the payment data held within TMS. If the
identity of the customer needs to be verified, the PAS Help Desk will
provide verification questions for the clerk to ask the customer and
advise the reply.
If payment appears in order, the PAS Help Desk will advise the payment
details, provide an encashment reference and update the payment record,
The clerk will complete a manual receipt using details displayed on the
card and the payment information provided by the PAS Help Desk.
When the failure is rectified the PC filestore will be re-synchronised from
TMS which has transiently become the holder of the more current
dataset. Following the failure, the clerk will select the ‘BENEFIT
ENCASHMENT (CARD) option from the ‘Contingency Mode’ menu in
order to access the ‘Contingency Mode - Benefit Encashment (Card)’
séreen.
The ‘Contingency Mode - Benefit Encashment (Card)’ screen will
provide the PAN, customer name, NINO, encashment reference and
amount for all payments recorded by the PAS Help Desk during the
failure period. The clerk will check the r¢-cipts against the payment
details displayed on the screen and, if correct, select the ‘CONFIRM
CORRECT? option. If incorrect; the clerk will contact the PAS Help
Desk in order to resolve the discrepancy.
Duplicate Receipt Request
The clerk will telephone the PAS Help Desk and advise the customer’s
NINO and the card issue number. The PAS Help Desk will advise details
of the last benefit encashed at the attended post office. If the identity of
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 212
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
the customer needs to be verified, the PAS Help Desk will provide
verification questions for the clerk to ask the customer and advise the
reply. The clerk will complete a manual duplicate receipt using details
displayed on the card and provided by the PAS Help Desk.
When the failure is rectified the PC filestore will be re-synchronised from
TMS which has transiently become the holder of the more current
dataset.
Change Of Nominated Post Office
The clerk will telephone the PAS Help Desk and advise the customer’s
NINO and the card issue number. The help desk will, if so determined
by DSS, verify the identity of the customer by providing verification
questions for the clerk to ask the customer and advise the reply.
Providing it is in order for the customer’s nominated office to be
changed, the PAS Help Desk will update the customer’s record and the
clerk will advise that the change has taken place.
When the failure is rectified the PC filestore will be re-synchronised from
TMS which has transiently become the holder of the more current
dataset.
4.2.8.2 OBCS
The following transactions are affected by PC failure in a single counter
office:
e Receipt of order books in post office
e Collection of order book by customer
e Benefit encashment using foil
4.2.8.2.1 CONTINGENCY ARRANGEMENTS
Receipt Of Order Books In Post Office
The card order book receipt function will be left until the failure has
been rectified.
Cotlection Of Order Book By Customer
The clerk will request the customer to return when the failure has been
rectified.
Benefit Encashment Using Foil
The clerk will telephone the PAS Help Desk and advise the customer’s
NINO. The PAS Help Desk will provide details of any stops placed and
a reference number. If allowable, the clerk will then encash the foil.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 213
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Following the failure, the clerk will select the ‘BENEFIT
ENCASHMENT (FOIL) - OBCS’ option from the ‘System Failure’ menu
in order to access thé ‘Contingency Mode - Benefit Encashment (Foil) -
OBCS’ screen.
The ‘Contingency Mode - Benefit Encashment (Foil) - OBCS’ screen will
prompt the clerk to key the following payment details for each order
book encashment made during the failure period:
e Benefit group
¢ Foil amount
e¢ Number of foils
e¢ Number or milk tokens
e PAS Help Desk reference
This will enable details for cash account and stock management purposes
to be posted to EPOSS and payment volume details to be passed to TMS.
In the event that the order book required impoundment, this will have
been recorded by the PAS Help Desk.
4.2.8.5 EPOSS
4.2.8.3.1 CONTINGENCY ARRANGEMENTS
The clerk will complete all EPOSS transactions using current manual
procedures. Receipts for these transactions will be manually produced
where required, as for printer failure occurrences.
When the failure is rectified, the transactions completed during the
period of failure will need to captured: In order to do this, the clerk will
select the various transaction options from the ‘Contingency Mode’
menu. The ‘Contingency Input’ screen for each transaction will prompt -
the clerk to key required information, either from documents or receipts,
to record transaction details in the journal record and post details to
EPOSS for cash account and stock managernent purposes.
4.2.8.4 APS
Magnetic and Smart card / key transactions are affected by PC failure in a
single counter office.
4.2.8.4.1 CONTINGENCY ARRANGEMENTS
Magnetic Card Transactions
Both card and payment details are recorded by completing a manual
receipt with card details using an ‘imprinter’.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 214
FUJ00119561
FUJ00119561
Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Pathway
When the failure is rectified, the transactioris completed during the
period of failure will need to captured. In order to do this, the clerk will
select the various transaction options from the ‘Contingency Mode’
menu. The ‘Contingency Input’ screen for each transaction will prompt
the clerk to key required information, from the receipts, to record
transaction details in the journal record and post details to EPOSS for
cash account and stock management purposes.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 215
FUJ00119561
FUJ00119561
1
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Smart Card / Key Transactions
There are no contingency arrangements available for Smart Card / Key
transactions. During periods of PC failure these transactions will not be
completed.
4.2.9 PC FAILURE - MULTI-COUNTER OFFICE
4.2.9.1 BES (GATEWAY PC)
In the event of a failure involving the PC supporting the ISDN gateway
in a multi-counter office, the office may continue with BA card
transactions which involve local authorisation data and the local NINO
list. However, data relating to these transactions will be passed to
central systems until the fault is rectified.
4.2.9.1.1 CONTINGENCY ARRANGEMENTS
In the event of encashments using cards fe. which local authorisation
data is not available, for example, foreign and emergency encashments,
the clerk will contact the PAS Help Desk as detailed for PC failure in a
single counter office. In these cases, however, the system will prompt the
clerk to contact the PAS Help Desk and will display the ‘Manual
Authorisation’ screen. The ‘Manual Authorisation’ screen will prompt
the clerk to key the following details:
Cardholder’s name
Cardholder’s NINO
Beneficiary’s name and NINO (if different)
Payee role (if required)
Total amount encashed
Milk token type ahd number
Unique encashment transaction identifier
e oe ee ee
The clerk will key the necessary details from the card and the payment
information provided by the PAS Help Desk and the receipt will be
produced automatically by the system.
In the event of permanent agent and alternative payee encashments,
although local authorisation data:is available, there is the risk that
payment has been made elsewhere and the local record has not been
updated. In these cases, the system will prompt the cierk to contact the
PAS Help Desk to confirm the local payment.
When the network connection is resumed, the post office, which is the
holder of the more current dataset, will re-synchronise with TMS.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 216
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Transactions which were recorded locally after contacting the PAS Help
Desk will be automatically compared to the centrally held encashment
records and any inconsistencies will be flagged for investigation and
rectification.
In circumstances where the remaining counter positions are unable to
handle the volume of EPOSS customers, contingency arrangements as
detailed for PC failure in a sing!* counter office will be envoked.
4.2.9.2 BES (NON-GATEWAY PC)
4.2.9,2.1 CONTINGENCY ARRANGEMENTS
The failed PC may not be used and, wherever possible, BA customers will
be directed to other counter positions on which BA transactions will
form the priority transaction. In extreme circumstances where the
remaining counter positions are unable to handle the volume of
customers,
contingency arrangements as detailed for PC failure in a single counter
office will be invoked.
4.2.9.3 OBCS
4.2.9.3.1 CONTINGENCY ARRANGEMENTS
The failed PC may not be used and, wherever possible, BA customers will
be directed to other counter positions on which BA transactions will
form the priority transaction. In extreme circumstances where the
remaining counter positions are unable to handle the volume of
customers, contingency arrangements as detailed tor PC failure in a
single counter office will be invoked.
In the event of foreign OBCS encashments, the clerk will need to contact
the PAS Help Desk to ensure that there are no stops on the payment and
will then encash the foil in the normal manner.
4.2.9.4 EPOSS / APS
4,.2.9.4.1 CONTINGENCY ARRANGEMENTS
The failed PC will not be used and, wherever possible, EPOSS / APS
customers will be directed to other counter positions. However, BA
transactions. will form the priority transaction on the other counter
positions in the office.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F. DOC Page 217
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
In circumstances where the remaining counter positions are unable to
handle the volumes of EPOSS transactions, contingency arrangements as
detailed for PC failure in a single counter office will be invoked.
4.2.9.5 PC FAILURE IN MID CUSTOMER SESSION
If a PC is subject to failure mid way through a customer session, all
transactions not committed will be lost. BA transactions, although
transacted as part of a customer session, which due to their nature are
committed in their own right, are not affected provided they have been
committed prior to system failure.
4.2.10 NETWORK FAILURE - ISDN CONNECTION
4.2.10.1 BES / OBCS
4.2.10.1.1 CONTINGENCY ARRANGEMENTS
The situation regarding an ISDN faiure in any post office is the same as
a failure involving the PC supporting the ISDN gateway in a multi-
counter office and the same contingency arrangements will apply.
4.2.10.2 EPOSS / APS
4.2.10.2.1. CONTINGENCY ARRANGEMENTS
The clerk may continue normal operations in the event of an ISDN
failure in the post office. However, whilst transaction details will be
recorded in the journal record and details posted to EPOSS, it will not be
possible for data to be transmitted to TMS and, in the event of
automated payments, to the client.
4.2.11 SITE RELATED FAILURE
The following are examples of site-related failures which may arise:
e Whole areas with many adjacent post offices fully or partially disabled
through widespread loss of power due to storm, flood, terrorism, war
or civil commotion
Individual offices incommunicado
Individual offices with no power
Individual offices with fabric affected but having power
Individual offices completely destroyed
4.2.11.1 BES / OBCS
4.2.11.1.1. CONTINGENCY ARRANGEMENTS
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 218
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
The contingency arrangements invoked will depend on the nature and
exteat of the site-related failure. The following are examples of the
options that may be available to sustain BA transactions:
e Invoke contingency arrangements as detailed for PC failure in a single
counter Office
e Temporary transfer of payment / OBCS data to another post office in
close proximity
¢ Mobile post office established
e Emergency power source brought to site
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F. DOC Page 2i9
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.2.11.2 EPOSS ; APS
4.2.11.2.1. CONTINGENCY ARRANGEMENTS
The contingency arrangements invoked will depend on the nature and
extent of the site-related failure. The following are examples of the
options that may be available:
¢ Invoke contingency arrangements as detailed for PC failure in a single
counter office
e Mobile post office established
e Emergency power source brought to site
4.3 RELEVANT OPTIONAL POCL SERVICES
4.3.1 BES
To be agreed with following consultation with POCL.
4.3.2 APS
To be agreed with following consultation with POCL.
4.3.3 EPOSS
To be agreed with following consultation with POCL.
4.3.4 POCL INFRASTRUCTURE SERVICES
To be agreed with following consultation with POCL.
4.3.5 ORDER BOOK CONTROL SERVICE
4.3.5.1 INTRODUCTION
The Order Book Control Service (OBCS) is. an optional service which
provides various functions associated with the use of bar-coded Order
Books by BA customers in post offices who are in receipt of various,
typically long-term benefits (e.g. Child Benefit, Retirement Pension).
These functions centre around the receipt and use of stop notices which
direct the post office clerk to stop, recall or otherwise restrict the
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 220.
Pathway
FU,
Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
FUJ00119561
}JO0119561
4.3.5.2
payment of order book based benefits when deemed necessary by the
DSS.
Stop Notice data records are received from the DSS ESNCS computer
system and processed by the OBCS Host system. This information is
then made available to post offices where the OBCS counter application
uses the stop notices to determine whether a payment request should be
made or restricted in some form.
The OBCS counter application, also enables the post office to verify that
Order Books received, and about to be issued, have not been
subsequently stopped.
The results of all OBCS transactions from all post offices are
accumulated during the day and made available to the OBCS Host
system via TMS. The OBCS host system will then collate these
transactions and dispatch them in an agreed format to the DSS ESNCS
system.
OBCS FUNCTIONS
OBCS can be considered as comprising two groups of functions :-
(a) OBCS Host functions
These are functions chat relate to the receipt and dispatch of data to/from
the DSS ESNCS system and to/from TMS together with all associated
processing. This will include the management of stop list data, data
reformatting prior to transfer to ESNCS or TMS and any transaction
collation as required by ESNCS.
(b) OBCS Counter Functions
Those functions that relate to the tasks performed at the post office,
either in the back office or at the counter. The back office functions will
include the checking of Order Books against a stop list upon receipt and
prior to issue ro the BA customer. The counter functions will include the
checking of the order book against the stop list whenever one is
presented for payment and the enactment of the BA business rules
associated with any stop notice that may be present.
All OBCS transactions will be recorded using the generic facilities
provided by OPS ard replicated to TMS.
Printed: 2.
C:\FINALPI
COMMERCIAL IN-CONFIDENCE
Page 221
FUJ00119561
FUJ00119561
1
Pathway Ref: PES/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.3.5.3 OBCS HOST FUNCTIONS
The ORCS Host Functions will be provided on servers operating within
the Pathway datacentres. They will link to the central TMS servers and
will provide the interface to the DSS ESNCS computer system. The
operational characteristics, data and interface requirements for these
functions will be described in DSS Client Interface Specification - OBCS'.
The OBCS Host functions are :-
Process OBCS Stup Notice Update
This process manages the receipt of the daily Stop List update file from
the DSS ESNCS computer systems and the subsequent dispatch of stop
list records to certain post offices.
The operational characteristics and technical interface to the ESNCS
computer systems is described in che DSS Client Interface Specification-
OBCS' together with the procedures for dealing with success and failure
conditions (e.g. transfer failure, corruption or non-arrival). Details of
the file status, date/time etc. are recorded as part of the OBCS Host log
for operational control and service-level use.
Validation of the data file will comprise a check for a sequentially
increasing file number and a check of the record count within the file
against the trailer record value. The Stop list is then processed according
to the validation criteria specified in the OBCS Processing Rules' . The
Master stop list is updated and the individual stop records are then
distribured to the relevant post office. Any reject records are returned ro
Dss
This distribution process uses the numinated post office details contained
in every OBCS stop record.
Process OBCS Transactions
' Pathway expects this document to be produced by DSS. The content
and ongoing management of the document have yet to be agreed.
Pathway expects this document to be produced by DSS. The content
and ongoing management of the document have yet to be agreed.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 222
Pathway
FU,
Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
FUJ00119561
}J00119561
4.3.5.4
4.3.5.4.1
This process manages the accumulation of OBCS transaction records
from TMS during the day and appends these records to the daily ESNCS
transaction file.
As part of the end of day process in each outlet, the number of non-
barcoded vouchers encashed will be recorded and transmitted via TMS.
These records are processed, stored and dispatched to DSS as separate
file.
The non-arrival of these end-of-day OBCS records will monitored and
used for service level management.
At the agreed time all OBCS transactions are transmitted to DSS as a
single daily batch file.
Request Full Stop List
This is an occasional process which may be initiated by DSS or Pathway
and will operate as a batch file transfer. Following receipt of the full
stop list an exception report will be produced highlighting any
differences between the new and the current stop list.
STOP LIST PROCESSING
LOCAL STOP LIST
OBCS uses a local stop list to minimise the requirements for a UK-wide
stop list to be processed in every post office. The stop list records
received from the ESNCS system will contain the nominated post office
of the DSS customer. Each stop notice record is then only distributed to
the specific nominated post office. This process will create a local stop
list for each post office. The local stop list will be maintained in the
outlet by following the action code contained in each record received :-
Action Code Action
Stop Add to list
Recall Add to list
Purge Remove from list
!DN: Pathway anticipate that the ESNCS stop record can be enhanced to
include the nominated post office of the DSS customer]
[DN: DSS to supply details for calculation of date of recall]
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 223
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4,.3.5.4.2 LOCAL NINO FILE SYSTEM
OBCS is supported by the Local NINO File System (LNFS) which
produces a local NINO list in every post office. This is to enable OBCS
to determine whether a customer is in his nominated office. The local
NINO list will be established in every post office from information
provided by DSS.
[DN: The implementation and early operation of OBCS can be simplified
if a beneficiary/nominated office list is provided by DSS. }
OBCS will check the bar-code details against. the local NINO list and if a
match is found then a check is.made against the local stop list. If no
entry is found on the local NINO list the OBCS counter a; plication will
request a search against a centrally held stop list.
The local NINO list will be maintained in the outlet by following the
action code contained in an LNFS change record. These records will be
created by the LNFS Host system following receipt of details from CMS.
CMS will routinely receive changes to customer personal details. CMS
will additionally forward relevant details to the LNFS Host system where
these changes relate to :-
e New Customer
e Customer no longer of interest
e Change of nominated post offic?
The LNFS Host system will then create LNFS change records with action
code of “add” or “delete” as required and then distribute these change
records to the relevant post office.
The local NINO file may also be updated in the outlet when a valid
order book has been presented, the NINO is not present on the local file,
yet the address on the book cover is that of the post office where the
transaction is taking place.
[DN: this process to be agreed with DSS. The alternative is that the
payment may proceed and an exception record be produced.]
4.3.5.5 OBCS COUNTER FUNCTIONS
The OBCS Counter functions relate to the tasks associated with the
initial receipt and issue of Order Books and the subsequent payment of
one or more foils upon presentation by BA customers.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 224
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
OBCS operates on a negative stop basis, whereby the presence of a stop
notice will result in some form of restricted counter transaction. The
absence of a stop notice will allow book receipt, book issue or payment
to proceed.
The OBCS counter functions are’ :-
4.3.5.5.1 RECEIPT OF ORDER BOOKS IN POST OFFICE (OBCS)
Order books received in a post office are recorded in OBCS.
Transaction Selection
The clerk will be required to select the ‘ORDER BOOK RECEIPT’
option from the ‘Desktop’ menu in order to access the ‘Order Book
Receipt’ screen.
4.3.5.5.2 STEADY STATE SERVICE PROVISION
Counter Activities
The ‘Order Book Receipt’ screen will prompt the clerk to read the bar-
code of each order book received. The clerk will select the ‘LAST
BOOK’ option when all books have been swiped. The order books will
then be stored in a secure location.
Exceptions
I. Bar-code cannot be read:
Following three unsuccessful attempts to read an Order Book the clerk
will be prompted to key the bar-code information and impound book.
Clerk will key bar-code, select ‘IMPOUND’ option, hole-punch book
and return itto BA. An audible warning will denote an unsuccessful
read.
2. Bar-code is not held on local NINO list:
The Clerk will be prompted to check printed address on order book.
If printed address corresponds with PO address, clerk will select
“CORRECT” option and local NINO list will be updated. If printed
address does not correspond with PO address, clerk will select
‘INCORRECT? option, key PO code of correct PO and re-direct order
book.
Printed: 22/05/96 COMMERCIAL. IN-CCNFIDENCE
C:\FINALPRN'PFISCT4F.DOC Page 225
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/OO1L
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.3.5.
in
Additional procedures will be required to stipport the valid issue of a
re-directed Order Book whose address does not match that of the
issuing post office.
Ue
. Stop or matured recall notice present on stop list:
Clerk will be prompted to impound book. Clerk will select
‘IMPOUND option, hole-punch book and return it to BA.
+. Instruction already placed to re-direct order book to another post
office! :
Clerk will be prompted to re-direct order book to another PO? for
which PO code will be provided. Clerk will select ‘RE-DIRECT’
option and forward order book to correct PO.
: 1
. Instruction already placed to return order book to BA’:
Clerk will be prompted to return order book to BA. Clerk will select
“RETURN TO BA’ option and return order book.
. PO subsequently receives instruction to forward order book to
another PO or return it to BA after receipt has been confirmed:
The process by which the postmaster is alerted to the receipt of this
instruction will need to be agreed. with DSS/POCL.
Clerk will locate order book from seeuré location: sivipe bay-code,
select appropriate option and forward order book to correct location.
OUTPUTS
Reading of bar-codes on order books using the “Order Book Receipt’
screen and selection of IMPOUND’, ‘RE-DIRECT’ and “RETURN TO
BA’ options. will enable details of order books received, accepted,
impounded, re-directed and returned to be passed to TMS.
Notes:
' Discussions and agreement are required between BA and Pathway to
define how re-direction instructions are to be placed.
> OBCS support for the subsequent operational procedures, and a
method of discriminating between re-directed and incorrectly delivered
Order Books is required.
Printed
C:\FINALPRN\PFISCT4F. DOC Page 226
22/05/96 COMMERCIAL-IN-CONFIDENCE
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Other exceptions, in addition to those listed and which arise at present,
will continue to be handled in the same way.
Post offices without OBCS will handle receipt of order books as at
present.
4.3.5.5.4 COLLECTION OF ORDER BOOK BY CUSTOMER (OBCS)
The customer will present the DSS Form of Authority (for first book) or
the current expired order book at a post office running OBCS in order to
collect the new order book. OBCS will not record any details contained
on the Form of Authority or the expired book.
TRANSACTION SELECTION
The clerk will be required to select the “ORDER BOOK ISSUE’ option
from the ‘Serve Customer’ menu in order to access the ‘Order Book
Issue’ screen.
4.3.5.5.5 STEADY STATE SERVICE PROVISION
Counter Activities
To complete the transaction the clerk will be required to:
e Check Form of Authority or current expired order book
e Request proof of identity (if Form of Authority présented)
¢ Obtain order book from storage location
e Check details on order book agree with details on Form of Authority
e Read bar-code on order book
e Date stamp order book
e Hand order book to customer
e Place Form of Authority in drawer or destroy expired order book
Exceptions
1. Bar-code cannot be read:
Having swiped the book three times unsuccessfully, clerk will be
prompted to key the bar-code information and impound book. Clerk
will key bar-code, select ‘IMPOUND?’ option, hole-punch book and
return it to BA.
2. Stop or matured recall notice placed on order book:
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F. DOC Page 227
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Clerk will be prompted to impound book. Clerk will select
‘IMPOUND?’ option, hole-punch book and return it to BA.
4.3.5.5.6 OUTPUTS
Reading of bar-codes on order books using the ‘Order Book Issue’ screen
and selection of IMPOUND’ option will enable details of order books
issued and impounded to be passed to TMS.
Notes:
Other exceptions, in addition to those listed and which arise at present,
will continue to be handled in the same way.
Post offices without OBCS will handle issue of order books as at present.
4.3.5.5.7 CUSTOMER'S VIEWPOINT
The customer will present the PUN or current expired order book to the
clerk. If PUN is presented, rhe customer will be required to provide
suitable proof of identity. The customer will be presented with a new
order book which may be used for benefit encashment.
4.3.5.5.8 BENEFIT ENCASHMENT USING FOIL (OBCS)
The customer will present order book at post office with OBCS in order
to encash benefit.
TRANSACTION SELECTION
The clerk will read the bar-code on the order book in order to access the
“Benefit Encashment (Foil) - OBCS’ screen.
4.3.5.5.9 STEADY STATE SERVICE. PROVISION
Counter Activities
The ‘Benefit Encashment (Foil) - OBCS’ screen will display the order
book bar-code details. The screen will prompt the clerk to pay the
customer and enter payment details.
To complete the transaction the clerk will be required to:
e Check order book and foil(s)
e Date stamp foil(s) and counterfoil(s)
e Remove foil(s) from order book
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 228
FUJ00119561
FUJ00119561
Pathway Ref PFS/PA/OOL
DSS/POCL Functional Specification Version. 3.0
Date: 22/5/96
e Return book to customer
© Key payment details: Benefit group, foil amount, number of foils
(default of one) and number of milk tokens.
© Pay customer - in accordance with total amount shown
e Commit the transaction and be returned to the ‘Serve Customer’
menu
© Place foil(s) in drawer
Exceptions
1. Bar-code cannot be read:
Having swiped the book three times unsuccessfully, clerk will be
prompted to key the bar-code information, encash one foil and
impound book. Clerk will key bar-code and details of one foil
payment, select ‘IMPOUND’ option, hole-punch book and return it to
BA.
2. Stop placed on order book:
Clerk will be prompted to impound book. Clerk will select
IMPOUND’ option, hole-punch book and return it to BA.
3. Matured recall notice placed on order book:
Clerk will be prompted to encash foils up to date of recall and
impound book. Clerk will encash allowed payments, select
“IMPOUND” option, hole-puncl: book and return it to BA.
4. Clerk suspicious:
Clerk will impound book. Clerk will select ‘IMPOUND’ option, hole-
punch book and return it to BA.
5. All or part of payment is required as cheque payment:
Clerk will select ‘CHEQUE PAYMENT? option and input amount of
payment required by cheque.
4.3.5.5.10 OUTPUTS
Committing transaction will record transaction details in the journal
record, post details to EPOSS for cash account and stock management
purposes and enab'e payment and impoundment details to be passed to
TMS.
Printed: 22/05/96
COMMERCIAL-!N-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 229
Pathway
FU.
Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
FUJ00119561
IJ00119561
4.3/5.5.11
4.4
4.4.1
CUSTOMER’S VIEWPOINT
The customer will sign the foils to be encashed and present the order
book to the clerk. The order book will be returned with the counterfoils
of the removed foils date stamped and the customer will receive
payment.
Notes:
Other exceptions, i:i addition to:those listed and which arise at present,
will continue to be handled in the same way.
An optional future output would be the production of the Pensions and
Allowances Summary.
POCL SERVICE INFRASTRUCTURE
This section describes the third element of the POCL Service
Architecture, namely the central IT and network infrastructure.
The central services layer for the PSI comprises the IT infrastructure
required to support the Transaction Managemeat Service (TMS), the
network infrastructure required to support WAN links to OPS and links
to Host systems, and the support environment required for help desks.
HARDWARE
The following diagram shows the complete Pathway central services
layer.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 230
FUJ00119561
FUJ00119561
I
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Pathway Operational Centre Infrastructure - Overview
POCL Chesterfield
Fe
. I
Be LG
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 23)
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date 22/5/96
4.4.1.14.1 EQUIPMENT DETAILS
The equipment and services shown above that relate to the POCL Service
Infrastructure are as follows :-
Item Description
Correspondence Multi-processor servers
Server housed in a rack system and
located in each datacentre.
Host Servers Multiple servers supperting
the receipt, storage,
processing and dispatch of
POCL or POCL Client
transactions and reference
data.
System Management I Duplex servers running in
servers each datacentre.
Network A server running in each
Management servers I datacentre.
FDDI Duplex FDDI 100Mbys in
each datacentre.
WAN Rourer High speed resilient router
located ar cach datacentre
and supporting encrypted
inter-site links and links to
CAPS service.
ISDN Primary rate Resilient primary rate ISDN
router routers located in each
datacentre
4.4.1.1.2 CORRESPONDENCE SERVERS
A configuration of Correspondence Servers will be established in the two
datacentres. Each will operate under Windows NTand will run Riposte
together with a number of TMS Agent processes which collectively
provide the functionality required for TMS.
The Correspondence Servers will use a rack mounted system which
enables two processor/disc configurations to be physically housed in a
22/05/96
C:\FINALPRN\PFISCT4F.DOC
COMMERCIAL-IN-CONFIDENCE
1
o
Page
Pathway
FUJ00119561
FUJ00119561
Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4.4.1.1.3
4.4.1.1.4
44S
single rack together with a morlitor and keyboard. Each Operational
centre will contain half the Correspondence Server configurazion.
Final load balancing and performance optimisation will take place during
the integration and test phases, which may require some adjustments to
be made to the above configuration (e.g. disc capacity and layout,
memory size etc.)
Each Correspondence Server will connect to two independent FDDI
100Mb/sec LANs. The first providing connection to the PAS and CMS
servers, and the second providing connection to the primary rate ISDN
routers.
An archive system will be established in each datacentre for the
correspondence servers. Data will be archived after 90 days and will be
written to a long term optical storage device.
HOST SERVERS
A variety of servers will be established to provide support for Client Host
processing and communication. These will typically be separate
Windows-NT servers each providing the host processing support for one
or more of POCL or POCL Clients. This will entail extraction of
appropriate TMS records, in-flight reformatting and temporary storage,
followed by end of day consolidation and file dispatch.
The final configuration for each Host server will be determined
following agreement of each Client Interface specification. This will
include any interim and final requirements for POCL involving initially
the AP-Hosts system and eventually the TIP system.
PATHWAY OPERATIONAL MANAGEMENT
The operational management of the Pathway systems will use servers
located in both Operational Centres to support the Network
management and Systems management facilities.
NETWORK INFRASTRUCTURE
The local area network within each datacentre is based on dual FDDI
providing separate network topologies for the Pathway central systems
(PAS/CMS) and the Host servers and separation from the Wide Area
Network and links to post offices. The physical and logical link fiom
Printed: 22/5/96 COMMERCIAL -IN-CONFIDENCE .
C:A\FINALPRN\PFISCT4F.DOC Pa
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
the post office/WAN domain to the Central Systems/Client Host domain
is provided by the Correspondence Servers (TMS).
4.4.2 SOFTWARE
4.4.2.1 SYSTEMS MANAGEMENT
A central Systems Management Service will be deployed, based ona
central service delivery capability able to interact with the outlets
through the PSI network infrastructure based upon IP
addressing/protocol structure and ISDN communications connections.
The following Systems Management services are provided:
4.4.2.1..1 REMOTE OPERATIONS
Facilities are provided for authorised inwards access to the OPS for the
purposes of remote control. This will enable central staff to undertake
specific fault analysis or diagnostic activities or to update underlying
software parameter data at the counter PC. The facility will be restricted
to central operations and help desk staff and wi!l normally operate as the
result of a call from POCL staff or agents for assistance. This facility is
implemented in conjunction with the standard Microsoft NT workstation
capability and operates via the standard ISDN network infrastructure.
4.4.2.1.2 STATISTICS
EPOSS will provide as part of its local reference data a histogram (table)
of transaction component timings fur each application’s core transaction
types. At the end of a customer serve transaction the relevant application
will pass to EPOSS the current values for incremental addition into the
histogram for that transaction type.
These times will include:
a) System Component Time - This is the running total of time within the
transaction consumed by system resource usage
b) Transaction Elapsed Time - This is the elapsed time for the
transaction measured from the earliest practical point (e.g. selection of
menu button or peripherally induced event) to the last practical
recording point (normally the completion of the transaction with the
final journal message written).
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 234
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
: DSS/POCL Functional Specification Version: 3.0
. Date: 22/5/96
Periodically the EPOSS function will log the table to persistent store as a
chec!point; end of day routines at counter level will write these tables to
the message store for replication to the central TMS, where a statistics
agent application will read and consolidate the records from the outlets
for transfer to the Pathway data warehouse for storage and analysis.
4.4.2.1.3 INVENTORY MANAGEMENT
A central database within the systems management function maintains
details of the hardware, software and applications asset base within the
installed OPS (Apart from hardware dependent components such as
Ethernet MAC addresses or processor serial number these will normally
be identical on all PCs at a particular outlet.)
This database will be available for enquiries by help desk staff as
necessary in responding to queries and calls from the outlets and will be
used by other components within the system stich as the software
distribution service. It will be updated automatically when any new
equipment is installed in an outlet or when new or updated software is
distributed and installed.
The database will be hierarchically structured, will employ SQL
technology and will be extensible to cope with any new
hardware/software objects/attributes deployed in response to future
services or applications needs.
4.4.2. 14 SOFTWARE DISTRIBUTION
Software distribution facilities enable software files and installation
scripts to be distributed to a specific outlet, all outlets or a group of
outlets selected according one or more particular attributes.
Software distribution is normally done in two stages:
a) distribution across the ISDN network from the central to the gateway
PC
b) local replication from the gatew
(where present)
The distribution process separates the transfer of the software to the
target device(s) and its subsequent installation, which is controlled from
the installation script associated with the software package. This enables
the installation process to take effect ata particular date or time.
y PC to other PCs in the outlet
Distribution to a specific PC within an outlet may be required under
specific-circumstances but will not be the normal mode of operation.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 235
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0.
Date: 22/5/96
CONFIGURATION MANAGEMENT FOR OUTLETS
The configuration details to be installed in each outlet will be maintained
on a central service; during roll-out this service will be accessed to down-
load the precise configuration (specific software and reference data)
applicable to each particular outlet and install the file set on all PCs
within the outlet. (This function will operate in conjunction with the Key
Management Service, which provides equivalent facilities for the
management and distribution of cryptographic keys.)
This service will also be available during steady state to support
equipment replacement at an outlet in situations where configuration
details cannot be loaded from a local PC (typically at single counter post
offices).
A specific aspect of configuration management is reference data
management applicable to each outlet. This will support the management
of outlet reference data, including that transferred from POCL via TIP
(or other means), and its transfer to each outlet. This facility will include
the ability to date/time stamp the point of «pplicability of reference data
changes.
4.4.2.1.6 EVENT MANAGEMENT AND ALERTS
Events occurring on equipment at the outlet will be trapped through the
Windows NT event system. This permits the consolidation of hardware,
software and application events; a filter mechanism is provides to classify
events into those requiring immediate action (alerts) and those deferred
for subsequent reporting (normally consolidated into end of day activity).
Alerts will be transferred through the network, causing ISDN sessions to
be established where required, and will be subsequently processed by.the
central Alert management facility. The precise resultant action will
depend upon the nature of the alert but will normally result in a
displayed status and warning message to the Pathway system
management staff.
4.4.2.2 NETWORK MANAGEMENT
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
CAFINALPRN\PFISCT4F.DOC Page 236
FUJ00119561
FUJ00119561
Pathway : Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Network management will be run from a central service providing
facilities for reporting and diagnosing network events, consolidation and
interrogation of statistics and controlling the configuration and
parameter settings on network devices.
The global system will be divided into three levels for network
management purposes:
a) The backbone network, comprising the LAN hubs and LAN
attachments at the Pathway central sites, the megastream links between
the Pathway sites, and to BA and POCL, with associated routers.
b) The branch ISDN network, terminated at the central routers and at
the gateway PC at each outlet. Management of the underlying switched
circuit network will be provided by BT, operating as part of the Pathway
consortium.
c) The office LAN at each outlet, comprising the PC LAN attachments
and local Ethernet hub (present where 3 or more PCs are installed). This
will include a proxy agent able to operate locally and, via ISDN, in
conjunction with the central network management service.
The network management facilities will be based primarily upon the use
of SNMP mechanisms, with additional facilities provided across the
ISDN network at platform level via the Microsoft NT event system and
associated middleware.
Security Services
The POCL service infrastructure includes security services to provide
data integrity, data privacy, authentication, access controls and audit.
Within the solution overall there is a separation between the central
domain, operating in a relatively secure environment, and the local post
offices domain, operating in a relatively untrusted environment and
interconnectéd by public switched network infrastructure.
The description below reflects discussions between Pathway and CESG
and may be modified.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 237
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
# Correspondence Servers"
EDSS Ay ACs, each,
id
Rowers
Bootle
Wigan,
Higure 1 Nenwoes selemaie ¢ Ontives
A summary of services provided within each level of the system is.
provided below:
Central Domain
The central domain, comprising the two Pathway sites and dara links
between them and to/from BA and POCL sites, is regarded as a trusted
base. Data will be stored in clear, although link level encryption will be
employed for data transferred between the two Pathway sites and to and
from BA and POCL sites.
Data processing platforms will provide security infrastructure based on
C2 level functionality with strict access controls and role based privilege.
Audit facilities will be provided on data flows to and from this domain
and also on staff access to central services within this domain. Physically,
equipment will be housed in secure accommodation.
ISDN branch network
The branch network provides facilities for ..thentication between called
and calling parties, using CLI at ISDN network level and CHAP within
the PPP link level protocol. Digital signature technology based on
SHA/DSA will be applied to sensitive data passing, across the ISDN
network between this central domain and the post office outlets. This
includes outbound benefit authorisations and inbound AP smartcard/key
transactions. Data encryption facilities to provide data content
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F. DOC Page 238
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
confidentiality are not required on data passing across the branch
network for the current transaction set (BES, AP, OBCS and FPOSS).
Local Office Environment
This is regarded as an untrusted domain and security facilities will be
provided to enable data confidentiality and integrity provisions to be
applied to sensitive data stored within the outlet. These will be based on
Red Pike and SHA/DS.\ cryptographic mechanisms respectively. Red Pike
encryption will be applied to BA data stored on disc at the outlet; BA
payment data wil! be verified at encashment using DSA and AP smart
transactions will be sealed using SHA/DSA when written to the journal at
the outlet.
The traffic across the post office LAN comprises replica transfers from an
originating PC to all other PCs in the LAN in the course of journal
replication. Most of this traffic will be Unclassified, or Restricted not
requiting cryptographic protection, and will be transferred in clear,
although some will be simple-compressed.
The local office platform will be based upon a secure (C2 equivalent)
version of Windows NT, providing object based labelling, user
authentication, access controls and audit facilities. Riposte will operate in
conjunction with the Windows NT security subsystem to police user log-
in and time-out of unattended workstations.
[DN - Consideration will be given to utilising ihe CESG-specified
Thunderflash one-way encryption algorithm for password privacy in place
of the native Windows NT one.I
The counter application data will bz accessible only to the authorised
application set. User access to native operating system facilities will be
inhibited.
The data management of the journal within the post office (and
extending to the correspondence servers), corresponds to a replicated
database of sequential files accessed only by read or appena methods.
There is no normal logical update access (except for archiving
middleware). Transactions give rise to one or more journal record
appends each with a unique message sequence reference number for
which the middleware maintains monotonic sets.
Key Distribution
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 239
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OOL
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
It is intended that all key material will be originated from CESG and held
securely in a central Key Management Server from which it will be
distributed. Key values themselves will be supplied by CESG in bulk to
Pathway’. Pathway will store these keys on a secure, resilient platform,
using Red Pike disk encryption. Renewal of keys will be required after
not more than six months
Key distribution within the 2 central sites will be handled in clear;
Rambutan provides link level encryption of key material transported
between the two central sites during distribution operations. Keys
distributed within the central domain are the DSA key for PAS payment
sealing and Red Pike keys for encryption of the DSA key during its local
storage on PAS agent platforms.
Key distribution to the individual post office outlets will be organised as
a rolling programme involving the update of approximately 800 outlets
per week during steady state operations. This will be done during periods
of natural operational quiescence, trpically 1 weekends. Keys distributed
to each outlet are the Red Pike key for loc. dise encryption, the DSA key
for AP payment sealing and the CHAP key for authentication during
ISDN link establishment
Key distribution will use the Diffie-Hellman key exchange algorithm
between the KMS and the gateway PC at an outlet to generate a shared
session key which will then be used to encrypt the 3. keys during their
transfer from the KMS to the outlet. Diffie-Hellman will be used at a
second level to a generate session keys during the subsequent distribution
of keys to other PCs within the outlet across the local LAN.
Red Pike will be used to enerypr the DSA and CHAP keys during storage
at the outlet. Encryption of the Red Pike key is possible via a master key,
although this generates problems of installation and subsequent update.
Consideration will be given to using secure surface mail of a memory
card for input by the postmaster using a Pathway supplied utility
operating under specific role protection. Alternatively, consideration will
be given to the use of a secure 2 way hashing algorithm for local storage
of the Red Pike keys.
For the purposes of symmetric encryption of data stored on disk, the
current session key will be common across the LAN-connected PCs
within a post office. A common DSA and (where applicable) CHAP key
will also be used across the PC community at an outlet.
Pathway could alternatively seek accreditation to generate its own key
stock.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 240.
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
Steps will be taken to ensure that the right session key is available to
decrypt a particular journal entry and that older session keys are held for
long enough to be available for decrypting the oldest journal entries.
Note that some journal entries, of a so-called persistent type, will be
unchanged for an undefined period of time and may also not be accessed
for an undefined period of time. Non-persistent journal entries will be
discarded (in the post office layer) after not less than about four weeks,
although this period is a function of available disk storage not of time:
in a low-volume, rural office the disk store occupancy may not force
discard for a year or so,
It will therefore necessary to re-encrypt such ageing records with the
current session key at, say, annual intervals so that the old session key(s)
with which they were originally encrypted can be discarded, and the
keylist tidied.
Distribution of keys to the Ramburan devices will be based on
proprietary key management systems provided by the chosen supplier.
Investigations will be made to ascertain whether this function can be
consolidated with the wider KMS functions described above; the aim is
to at least share-a common secure platform
4.4.3 OTHER COMPUTER & TELECOMMS EQUIPMENT
This section gives a brief description of those computer systems used
within Pathway for Help Desk and internal operations management
(specifically service level monitoring). It also sets out the
telecommunications equipment used for WAN data traffic, and the
telephone links for Help Desk communications.
The diagram in the section “POCL Service Infrastructure” gives an
overview of the network components.
4.4.3.1 OFS HELP DESK IT SYSTEMS
The OPS help desk IT systems will run on servers in two locations for
resilience. These will support the call management system requirements,
for incident logging and fault reporting to other help desks: the call
management system is integrated with other Sorbus systems (such as
spares logistics and engineer assignment) to provide a comprehensive
service.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 241
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.4.3.2 PATHWAY MIS
Large servers at Pathway operational centres will be used to run an
Oracle system which will support:
© service level agreement monitoring
¢ an alert management system
¢ asset/configuration management
© contract management
© invoicing
e ledgers
© fraud risk mana,ement analysis and reporting
© auditing
* ad hoc reports for policy development, and monitoring, Parliamentary
and Ministerial Questions
4.4.3.3 WAN INFRASTRUCTURE
The WAN infrastructure for bulk data transfers berween the DSS, POCL
and Pathway computer centres will be based on Megastream services.
These will be diversely routed for resilience, with data sent over the
WAN encrypted for security, using the Rambuzin mechanism or other
CESG approved method. Encryption units will be outboard of the high
specification Routers, which will be configured to provide resilience for
all links.
SMDS. may be used in place of Megastream services when the encryption
chipset can support the higher speeds.
ISDN services will provide the basis for WAN communications where the
level of data transfers is lower, specitically between the post offices and
the Pathway operational centres, and for automated payments between
the Pathway operational centres and the individual client centres. A
degree of resilience will be provided through the nature of the public
ISDN network, by over-configuring router connections at the Pathway
operational centres, and through the ISDN call management software in
supporting alternative addressing.
4.4.3.3.1 CAPS / PATHWAY LINKS
Diversely routed WAN links of minimum 2Mb/sec will be implemented
for each of the 4 DSS Area Computer Centres where.a CAPS link to
Pathway is required each having a link to each Pathway operational
centre.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 242
FUJ00119561
FUJ00119561
Pathway ° Ref: PFS/PA/O01
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
4.4.3.3.2 POCL/ PATHWAY LINKS
A diversely routed WAN link of minimum 2Mb/sec will be implemented
between POCL (Chesterfield) and each Pathway operational centre.
4.4.3.3.3 PATHWAY INTER-S!TE LINKS
A diversely routed WAN link between the two Pathway operational
centres will he established with sufficient capacity to meet peak traffic
loads in all foreseeable circumstances. This will be a minimum of 2 x
2Mb/sec lines, rising as required to meet the projected growth in traffic.
4.4.3.3.4 ISDN LINKS BETWEEN POST OFFICES AND PATHWAY
Basic rate [SDN2 services will be established at each post office, with the
computer system at each post office having a set of preferred numbers to
automatically call when a circuit needs to be established between a post
office and an operational centre. The set of numbers will be arranged to
optimise load balancing of traffic between post offices and che
appropriate Correspondence Servers, and to provide high levels of
resilience. Call management software will optimise the processes of call
set up, holding the call open, call disconnect.
Primary rate ISDN30 services wilt he established at the Pathway
operational centres (Euro ISDN standard 1421), configured such that
either centre can support the projected traffic from all post offices.
The ISDN traffic will be managed by resilient Router configurations at
each Pathway operational centre.
4.4.3.3.5 ON-LINE LINKS
The on-line links considered here include automated payments and
EFTPOS transactions.
Pathway will transfer automated payment details to individual clients on
a daily basis, normally overnight. The volumes involved indicate that the
ISDN infrastructure will be appropriate.
ISDN or a permanent on-line link will be used for EFTPOS payment
authorisations, depending on the Merchant Acquirer requirements.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 243
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
4.4.3.4 TELEPHONE CALLS TO HELP DESKS
All phone calls to the help desks will use standard 0345 “Lo-Call”
numbers.
Calls will be loggedand re-routed if necessary to the appropriate help
desk.
4.5 POCL SERVICE ENVIRONMENT
4.5.1 POCL COMPUTERS
Details to be supplied following consultation between POUL and
Pathway.
4.5.2 TELECOMMUNICATIONS
Details to be supplied following consultat’ sn between POCL and
Pathway.
4.5.3 BUSINESS OPERATING SYSTEMS & SERVICES
Details to be supplied following consultation between POCL and
Pathway.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFISCT4F.DOC Page 244
FUJ00119561
FUJ00119561
Pathway : Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
-) Date: 22/5/96
A. DATA FLOW DIAGRAMS
This section contains a set of data flow diagrams that represents
functionality described elsewhere within this document.
The captions of the diagrams should be sufficient to relate the diagrams
back to the relevant text.
There are two sets of diagrams: those that support an overview of the
system and those that describe the lower level detailed flows that support
each major function.
AL OVERVIEW
Benefit
Book
BES Interactions
Stops EPOS Interactions
AP interactions
NN ‘OBCS Interactions
\.
Payment Advice
Boneficiary Details
Authorised Payments
Stops
‘Changes
Enquiries ___
Encashment 5 fi Transactions
Acknowledgements
Rejections
Responses
Nominated PO Changes
Pick Up
FiSKLP Encuiries
Figure A-1: Context Diagram
This diagram shows how Pathway fits within the overall Benefits Agency
and Post Office Counters solution.
The round cornered box in the middle represents the whole of Pathway.
The square boxes surrounding it represent ‘External Entities’ - i.e.,
external to Pathway. The lines represent data flows between Pathway
and these External Entities. The annotation next to the lines identify the
data that flows.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC Page 245
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
This diagram is intended to be an illustration rather than a formal
definition - hence the data names are generalised.
Beneficiary, Details
Encashments
Ents Acknowledgements
! Rejections
: Beneficiary Details Responses
Authorised “ ayments Nominated PO Changes
Stops
i Changes
J Enquiries
Enriched Payments
Stops
Changes Encashments
Nominated PO Changes
Enriched Payments, Encashments
Stops Nominated PO Changes
Changes Transactions
BES Transactions
Pick Up —BenefitCard_ _ _
Notice EPOS Transactions
Figure A-2: Level 1 Diagram
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC Page 246
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
A.2 DETAILED DIAGRAMS.
A.2.1 KEY TO DIAGRAMS
The diagram below is a key to the following diagrams. Each shaped box
has a different meaning. The name within the box in this key identifies
what that style of box represents.
Data Flow _,
Figure A-3: Key to Data Flow Diagram Conventions
A process represents an IT component that manipulates the information
in some way.
An external entity represents some component that sits outside the scope
of the diagram and communicates with an internal process.
Conventionally flows between external entities are ‘not shown, but in this
case they are shown where they add to the overall understanding of the
diagram.
A data store is a mechanism by which data is held in a persistent manner
for a significant amount of time. Significant in this context means longer
than the processing time of the processes to which it connects - in other
words transient data is not held within a data store.
The data flow arrow is self explanatory.
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC Page 247
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
A.2.2 AP
AP Transaction Datails Reference Data I Transaction Details
“Transaction Details
Reference Data
AP Transaction Details
Card Detaiis
Payment Value
{Token Details)
Token/Bil
I — Payment 7
“Receipes =
Figure A-4: Automated Payment Service
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC Page 248
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
A.2.3 BPS
Card Batch Details
Card Activation Details Card Batch Details
Card Batch Bar Code
PUN Card Batch Benefit Card Details
PUN Bar Code
ps
PUN >
Benefit Card
Figure A-5: BPS, Card Management
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC Page 249
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
ce DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
i Authorised Payments
lEncashed Payments I
(Change of Nominated PO H
~~ Card Details
Enriched Payment
Encashed Payment
Change of Nominated PO
Encashed Payment
Enriched Payment ‘Change of Nominated PO
Change of Nominated PO
Receipt
Benefit Card Détails or
Token Details
Benefit Card
Cash
Receipt
Benefit Card or Token
Figure A-6: BPS, Normal Encashment using Card or Token
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC Page 250
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
A.2.4 EPcss
Note that within this section that describes the EPOSS processing
frequent use is made of ‘Reference Data’ within its own Data Store. This
data is populated by the Reference Data Management System, which is
not illustrated here.
Transaction Details
inpayment Detail
Payment
I Documentation >>¥
Receipt or
C Endorsed Document
Transaction Details
{Charge}
Figure A-7: EPOSS, Inpayment
Printed: 22/05/96
COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC
Page 251
Pathway Ref:
DSS/POCL Functional Specification Version:
Date:
FUJ00119561
FUJ00119561
PFS/PA/001
3.0
22/5/96
Transactisn Details
Value Limits
Vaiue Limits
Documentation
Ohswitiizs
1
}
Figure A-9: EPOSS, Girobank Withdrawal
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC
Page 252
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Transaction Type
Value
Payment :
/—{Documentationy >
Product
Transaction Details
Transaction Type
Value
Documentation
cash
Figure A-11: EPOSS, Miscellaneous Outpayments
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC Page 253
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
Transaction Details :
Postal Order Details, Cost
Payment
Postal Order(s)
{stamps}
Stock Type
{Quantity) Cost
ayment
Product
Figure A-13: EPOSS, Stock Sales (General)
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC Page 254
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
Transaction Details
IH Receive Money Form
Cash
Customer 1D
Details Authorisation Code
Figure A-14: EPOSS, Western Union Money Transfer (Receiving)
Printed: 22/05/96 - COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC Page 255
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
WU Send Details: Handling Charge
_Payment
Receipt
Customer Details Authorisation Code
Figure A-15: EPOSS, Western Union Money Transfer (Sending)
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC Page 256
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Date: 22/5/96
A.2.5 LOCAL NINO LIST
Redirect
New customer
Discontinue customer
Redirect
Redirect
New Customer I
Discontinue CustomerI
Redirect
New Customer I
Redirect Discontinue CustomerI
New Customer I
Discontinue Customer
Figure A-16: Local NINO List, Control Processing
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC Page 257
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
A.2.6 OBCS
Stop I Recall I Purag
I Stop I Recall
) Purge
Stop I Recall
Purge
Stop IRecallI I
Purge
Figure A-17: OBCS, Control Processing
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC Page 258
Pathway
Ref:
DSS/POCL Functional Specification
Date:
Version:
FUJ00119561
FUJ00119561
PFS/PA/OO1
3.0
22/5/96
OBCS Transactions
OB Bar Code +
{Impounded}
Stop OB Bar Code +
{Impounded}
Form of Authority
Form of Autho~y
or Expired Book
Order Book
Figure A-18: OBCS, Benefit Book Collection
Printed: 22/05/96
COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC
Page 259
Pathway
Ref:
Version:
DSS/POCL Functional Specification
Date:
FUJ00119561
FUJ00119561
PFS/PA/001
3.0
22/5/96
OBCS Transactions
‘OB Bar Code +
: {Stop I Return I Redirect}I
OB Bar Code +
{Last Book Signal}
I_Order Book __y
Figure A-19: OBCS, Benefit Book Receipt
Printed: 22/05/96
COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC
Page 260
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
WW OBCS Transactions
OBCS Encashment Details
OBCS Encashment Details Stop
Cash +
Benefit Book +
{Milk Tokens}
Figure A-20: OBCS, Benefit Encashment
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC Page 261
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: — 3.0
Date: 22/5/96
A.2.7 RECONCILIATION
Payment Authorisation Matched Authorisation
Stop Reconciliation Exception __!
—— Unencashed Balance t
Encashment Notification'
‘Stop Notification
Expiry Confirmation T
Failed Stop . Encashment Notification
‘Stop Notification
Enriched Payment! Expiry Confirmation
‘Stop Failed Stop
Figure A-21:PAS Reconciliation
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE .
C:\FINALPRN\PFIAPPA.DOC Page 262
Pathway
DSS/POCL Functional Specification
FUJ00119561
FUJ00119561
Version: 3.0
I
I
Ref: PFS/PA/001
Date: 22/5/96 I
A.3 DATA DICTIONARY
This data dictionary is not intended to cover the whole scope of
Pathway. Its purpose is to support the preceding data flow diagrams. In
a number of cases potential comiplexity within a diagram caused by too
many data flows has been rationalised by using a more general data flow
that is then defined in the following dictionary. Not all names used in
the diagrams are held within this dictionary - only those that are non-
trivial.
Item Name
Payment
Content:
Cash I Cheque I
Girobank Transfer I
DNS Warrant I Postal Order I
Redeemed Stamps
Notes
Payment made by a
Post Office customer
to the Post Office
Inpayment Details
DNS Deposit Details I
Girobank Deposit Details I
DVLA Licence Details I
TV Licence Details I
Other Licence Details I
Insurance Product Details I
Rent Payment Details I
Bunches Details I
BT Bill Payment Detaiis
DNS Deposit Details
Type DNS Deposit +
Account Number + Value
Girobank Deposit
Details
Type Girobank Deposit +
Account Number + Value
+{Fee} + {Reference
Number}
DVLA Licence Details
Type DVLA +
Licence disc serial number +
prefix number + taxation class
Value determined
from reference data
TV Licence Details
Type TV Licence + [Colour I
Mono] + {Refund B&W} +
{Blind Reduction}
Value determined
from reference data
Other Licence Details
Type Other Licence +
{Concession}
Value determined
from reference data
Insurance Product
Details
Type Insurance + Value
Printed: 22/05/96
COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC
Page 263
Pathway
DSS/POCL Functional Specification
Ref:
Version:
Date:
FUJ00119561
FUJ00119561
PFS/PA/OO1
3.0
22/5/96
Rent Payment Details
Type Rent Payment + Value +
[Card Payment I Voucher
Payment]
Bunches Details
Type Bunches -+ [Today I Next
Day] + Value
BT Bill Payment
Type BT Bill Payment + Value
Details + Account Number
DNS Withdrawal Type DNS Withdrawal +
Details Value
Girobank Withdrawal: I Type Girobank Withdrawal +
Details Girobank Transaction Type +
Account Number + Value +
{Fee} + {Authorisation Code}
Postal Order Details
Type Postal Order + Value* +
Value of Stamps + Fee
* Can be multiple
values for multiple
postal orders
OBCS Encashment
Details
OB Bar Code? + Foil Amount
+ Number of Foils +
{Cheque Component} +
{Number of Milk Tokens} +
{Impounded}
Key:
I represents ‘or’
+ represents ‘and’
{ } encloses an optional component
[] encloses a selection list from which only one entry must be chosen
Printed: 22/05/96
COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPA.DOC
Page 264
Ref:
Pathway . PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Call Enquiry Matrix Date: 22/5/96
B. Call Enquiry Matrix
KEY TO CMS/PAS HELP DESK CALL MATRIX
ABBREVIATION FULL TITLE,
SAL ANNOUNCE SALUTATION TO CALLER
INT INTRODUCTION - ASCERTAIN REASON FOR CALL
I TD. ESTABLISH I.D. OF CALLER
KEY KEY CARD, NINO DETAILS, BATCH BAR-CODE
SEA SEARCH FOR CARD DETAILS
PER CHECK PERSONAL DETAILS RELATING TO CUSTOMER
‘CMS CHECK CARD /PUN ORDER DETAILS/STATUS
PAS CHECK PAYMENT DETAILS
REL RELAY INFORMATION TO CUSTOMER VIA CALLER
ACT TAKE ACTION -E.G. INS STOPS, BLOCK AND RE ISSUE CARD/PUN
REF REFER CALLER TO BENEFIT AGENCY/APPROPRIATE AREA
CONF CONFIRM ACTION TAKEN AND WHAT CALLER CAN EXPECT NEXT.
END CLOSE THE CALL
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPB.DOC Page 265
FUJ00119561
FUJ00119561
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Call Enquiry Matrix Date: 22/5/96
REF SOURCE/ENQUIRY TYPE HELP SAL INT LD. KEY SEA PER CMS PAS REL I ACT REF I CONF I END
DESK
PO COUNTER CALLS
PO1 I Bar-code from batch of cards not recognised CMS v v v v v 7 7 7 7 7
PO? FAD code or batch number incorrect on card receipt. CMS v v v v v v v v 7
PO3 I Unable to locate card on list (e.g. expired) within PO. CMS Ed v v v 7 v v v 7 v
PO4 Payment details required,system down (Help Desk does not PAS v v v v v v Tv
authorise the. payment)
POS Payment details required’ and extended verification procedure PAS v v v v v v v Vv v
invoked, system down (Help Desk does not authorise the
payment).
PO6 I Foreign Encashment, payment details required, system down PAS Pa Pa 7 7 7 7 F
(Help Desk does.not authorise the payment).
POT Foreign Encashment, payment details required and extended PAS 7 7 7 Tv 7 7 7 7 77]
verification procedure invoked, system down (Help Desk does
not authorise the payment),
POS Report PUN found. CMS v v 4 v v v T 7
POO _I Report card found. CMS v v v v 7 7 7 7
PO 10 Change of Nominated Post Office when PO Counter down. CMS v v v v v v v 7 Pa
PO COUNTER - INAPPROPRIATE CALLS.
POIT I Query trom PO. CMS v v T 7 7
e.g. Order status of card and or PUN.
Cannot read PUN.
Card:to be impounded, reason sought.
Card missing/excess.
PO rings for payment details without card details.
Report losvstolen PUNs/cards.
Report non-received PUNs.
Foreign payment enquiries during roll-out
Misc enquiries.
Printed: 22/05/96
C:\FINALPRN\PFIAPPB.DOC
COMMERCIAL-IN-CONFIDENCE
Page 266
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001 ~
DSS/POCL Functional Specification Version: 3.0
Call Enquiry Matrix Date: 22/5/96
REF SOURCE/ENQUIRY TYPE HELP SAL INT LD. KEY SEA PER I CMS PAS REL. I ACT REF .I CONF I."END* I
DESK :
{
[_ BA OFFICE CALLS
BAL Report lost, stolen, damaged PUNs - NINO always available. CMS: v v v v v 7 T Vv
BA2 Report lost, stolen, damaged cards - NINO always available. CMS: v v v v v v 7 7
BA3 Payment history enquiries (restricted to-unencashed payments PAS v v v v v T
not yet expired, encashed payments yet to be reported back via
CAPS, or payment with stops that have yet'to expire
¢.g. Is a stop in place
Recently encashed payments, where cashed. when cashed,
by whom were they cashed.
Payments’currently outstanding.)
Activities will be different for NSI cases where call wit! be
transferred to supervisor.
BA 4 ‘What was the last payment made, not yet reported back to PAS v v v v v vo v
CAPS, before card STOP placed?
BA 5 I Insert Payment Stop. PAS. v v Ed 7 7 T 7
BA 6 I Enquiries regarding Card and PUN Status/History? CMS v Ed v T 7 7
BA 7 Report non received PUNs - NINO always available. CMS: v v v v v v v ra ra
BA 8 Report card not available at PO - NINO always available. CMS: ‘ v v v v v Pa 7
BA 9 _I Insert Termination or Suspension on Card. CMS v v v 7 T 7 T 7
BA 10 Card found. CMS: v v v v Jv Pa v
BAIL PUN found. CMS: v v v Jv v v 7 ra
BA 12 I Take order for emergency batch of temporary tokens. CMS, v 7 v 7 riled 7 7
BA OFFICE - INAPPROPRIATE CALLS
BALI Payment enquiries, details already referred back to CAPS. PAS: v v v v v 7 v
BAI2 ‘Amendments to static data (personal details and nom PO), CMS v v Vv T
BAI3 I Misc enquiries CMS T T T 7
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
C:\FINALPRN\PFIAPPB.DOC Page 267
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/001 ~
DSS/POCL Functional Specification Version: 3.0
Call Enquiry Matrix . Date: 22/5/96
REF SOURCE/ENQUIRY TYPE. HELP SAL LD. KEY SEA PER CMS I PAS REL I ACT REF
DESK
CUSTOMER CALLS
ccl Report lost, stolen, damaged PUNs - NINO available. CMS v v v v v v Tv T
CC2_I Report lost, stolen, damaged PUNs - NINO not available, CMS Tv v v 7 Rd T 7 7
cc3 Report lost, stolen, damaged Cards - NINO available. CMS v v v v v v PA Tv
cca Report lost, stolen, damaged Cards - NINO not available. CMS v v v v v Tv 7 7
ccs ‘Customer has not received PUN and also advises address CMS v v v v v v Pa T Pa
unsafe and mail shouldn't be sent there -NINO available.
cC6 ‘Customer has not received PUN and also advises address is CMS v v v v v v v T 7
unsafe and mail shouldn't be-sent there - NINO not available.
CCT_I Report non received PUNS - NINO available cws_[ 7 7 7 Z 7 7 7 7 7
CCB Report non received PUNs - NINO not available. cus I v v Z 7 7 T 7 7
cco ‘Card PUN Status. Enquiry - NINO available. CMS v v v v v 7
CC 10 ‘Card PUN Status Enquiry - NINO not available. CMS v v v v v T
CCTI_I Card previously reported losUstolen-now found - NINO CMS v v 7 v Tv 7 7
available.
CC 12 I Card previously reported losUstolen-now found NINO not CMS 7 7 7 7 7 7 7
available. :
cc 13 PUN previously reported los/stolen-now found - NINO CMS v v v v v v 7 iI
available.
CC14 I PUN previously reported losvstolen-now found - NINO not CMS: v v v v 7 7 7
available.
CUSTOMER - INAPPROPRIATE CALLS
CCI I Where is my money? CMS 7 v 7 7
Disputed entitlement.
Amend details on card.
Change of personal details.
Change of nominated Post Office.
Refuses to accept Card and or PUN,
Which PO have I nominated?
General complaints about the system.
Queries re changes‘to BA payment svstem or rates.
Disputed encashment,
General Benefit entitlement or history,
Queries regarding the transitional period between launch and
full automation of benctits.
Printed: 22/05/96
C:\FINALPRN\PFIAPPB.DOC
COMMERCIAL-IN-CONFIDENCE
Page 268
FUJ00119561
FUJ00119561
Pathway Ref: PFS/PA/OO1
DSS/POCL Functional Specification Version: 3.0
Call Enquiry Matrix Date: 22/5/96
[ Request to insert suspension on card
Misc enquiries.
CCl? Queries received from customers but we are unable to trace CMS v v v T T
customer record on CMS (excludes calls referred to in CCI).
Printed: 22/05/96 COMMERCIAL-IN-CONFIDENCE
Page 269
C:\FINALPRN\PFIAPPB.DOC
Pathway Ref: PFS/PA/001
DSS/POCL Functional Specification Version: 3.0
Call Enquiry Matrix Date: 22/5/96
REF SOURCE/ENQUIRY TYPE. HELP SAL INT LD, KEY SEA PER CMS PAS I .REL ACT REF CONF END
DESK . .
NON CUSTOMER CALLS
NCCT] Bomb threats cus [7 T 7 7 7
NCC 2 Nuisance calls. CMS v v v v v
NCC 3 Report found Cards and PUNs. CMS. v v v v v v
Printed: 22/05/96
C:\FINALPRN\PFIAPPB.DOC
COMMERCIAL-IN-CONFIDENCE
Page 270
FUJ00119561
FUJ00119561