TABLE OF CONTENTS
TABLE OF CONTENTS
1.0 MANAGEMENT SUMMARY ..
LL INTRODUCTION wescseseanessersese
1.2 MEETING THE BA/POCL PROGRAMME OBJECTIVES...
1.3 PATHWAY - THE SERVICE PROVIDER
4.3.4 FINANCIAL COMMITMENT....... fase
1.4 PROPOSAL FOR BA/POCL SERVICE ARCHITECTURE .
1.5 IMPLEMENTATION PROGRAMME .....0.0++« =
1.5.4. PATHWAY IMPLEMENTATION EXPERIENCE
1.6 RISK MANAGEMENT...
1.7 PARTNERSHIP IN BUSINESS DEVELOPMENT
1.7.4 CRITICAL SUCCESS FACTORS .....--2+esser0e
1.7.2 BUSINESS GROWTH WITH EXISTING CLIENTS ..
4.7.3 BUSINESS GROWTH WITH NEW CLIENTS ...
1.8 SUMMARY a
NNOOPRSB HERE
Bown
2.1 STRUCTURE OF THE PATHWAY PROPOSAL.
2.2 SSR CHAPTER 9...
2.3 POINT OF CONTACT.
2.4 NAVIGATING THE PATHWAY PROPOSAL ..
2.5 GLOSSARY OF TERMS...
2.6 PATHWAY TERMINOLOGY ..
2.6.1 IDENTIFICATION (CUSTO!
2.6.2 VERIFICATION (CUSTOMER VERIFICATION)..
2.6.3 AUTHENTICATION (CARD AUTHENTICATION)
2.6.4 AUTHORISATION (PAYMENT AUTHORISATION)
B.A INTRODUCTION ......cssscssseenseessneessee eo
3.2 PATHWAY THE COMPANY ..
3.3 THE SERVICE PROVISION......
3.3.1. INTRODUCTION TO SERVICE
3.3.2 SERVICE ELEMENTS .
3.3.3 SERVICE CREATION ..
3.3.4 SERVICE PROVING...
3.3.5 SERVICE IMPLEMENTATION .
3.3.6 SERVICE DELIVERY...
3.3.7 SERVICE TRANSFER..
3.4 BUSINESS DEVELOPMENT AND RELATIONSHIPS
3.4.4 INTRODUCTION TO BUSINESS DEVELOPMENT AND RELATIONSHIPS ...
3.4.2 POCL’S STRENGTHS ....sssssscssseeesssssessennes et
3.4.3 PATHWAY'S STRENGTHS IN BUSINESS DEVELOPMENT.
3.5 FINANCIAL INFORMATION .....ssssssoe0 esnuennnduasnereese
BRBGBBERSSooVWNh
Pathway Response to
OJEC Notice 94/S 165-58937/EN COMMERCIAL IN-CONFIDENCE Date: 08/06/95
FUJ00098232
FUJ00098232
TABLE OF CONTENTS
4 SERVICE AND SYSTEMS ARCHITECTURE
4.L INTRODUCTION veccsscccsssorenesserensers
4.1.4 INTRODUCTION TO SECTION 4.1.
4.4.2 THE STRUCTURE OF SECTION 4..
4.1.3 OVERVIEW OF THE SYSTEM AND SERVICE ARCHITECTURE PROPOSAL
4.1.3.4 SERVICE ARCHITECTURE...ssescssssssesserserssere
4.4.3.2 POCL STRATEGIC INFRASTRUCTURE SERVICI
4.1.3.3 BENEFIT PAYMENT SERVICE... sscsssssesssesseees
4.1.4 BENEFITS OF PATHWAY’S PROPOSED ARCHITECTURE
4.2 SERVICE ARCHITECTURE
4.2.4 INTRODUCTION oes
4.2.2 PATHWAY SERVICE ARCHITECTURE
4.2.2.1 INTRODUCTION TO THE SERVICE ARCHITECTURE
4.2.2.2 SERVICE ARCHITECTURE OVERVIEW.
4.2.2.3 BENEFIT PAYMENTS SERVICE...
4.2.3 KEY BUSINESS AND OPERATIONAL FACTOR:
4.2.3.1 BUSINESS PERSPECTIVES ....
4.2.3.2 BA ENTERPRISE MANAGEMENT
4.2.3.3 POCL ENTERPRISE MANAGEMENT.
4.2.3.4 EMPLOYEES ...
4.2.3.5 CUSTOMERS ..
4.2.4 SERVICE ARCHITE
4.2.4.1 INTRODUCTION TO SERVICE ARCHITECTURE PERSPECTIVES
4.2.4.2 SERVICE PROVISION OBJECTIVES .......
4.2.4.3 TECHNOLOGY PROVISION OBJECTIVES
4.2.5 PATHWAY’S SERVICES PROPOSA\
4.2.5.1 INTRODUCTION...
4.2.5.2 OVERVIEW OF PA
4,2,5.3 PHYSICAL ARCHITECTURE «..sessscessees
4.2.5.4 DELIVERY OF END-TO-END SERVICES.
4.2.5.5 TRANSITION OF EXISTING SERVICES.
4.2.6 PAYMENT MANAGEMENT SYSTEM
4.2.6.1 PMS OVERVIEW viesscsssssssreersrees
4.2.6.2 SYSTEM DESIGN FOR THE PAYMENT AUTHORISATION SERVICE.
4.2.6.3 PATHWAY PROPOSAL FOR PMS...
4.2.6.4 PMS OPERATIONAL CHARACTERIST!
4,2,6.5 PMS SERVICE QUALITIES .....
4.2.7 CARD MANAGEMENT SYSTEM
4.2.7.1 CMS OVERVIEW...sseseeeseee
4.2.7.2 PATHWAY PROPOSAL FOR CMS
4.2.7.3 CMS OPERATIONAL CHARACTERISTICS
4.2.7.4 CMS SERVICE QUALITIES ..
4.2.7.5 CARD TECHNOLOGY OPTIO!
4.2.8 TRANSACTION MANAGEMENT SERVICE.
4.2.8.4 TMS OVERVIEW ...essseeseseseeee
4.2.8.2 PATHWAY PROPOSAL FOR TMS.
4.2.8.3 TMS OPERATIONAL CHARACTERISTICS
4.2.8.4 TMS SERVICE QUALITIES...
4.2.9 COUNTER INTERFACE SERVI
Pathway Response to
OJEC Notice 94/S 165-58937/EN COMMERCIAL IN-CONFIDENCE Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
4.2.9.1 COUNTER INTERFACE OVERVIEW
4.2.9.2 PATHWAY PROPOSAL FOR THE COUNTER INFRASTRUCTURE
4.2.9.3 COUNTER INTERFACE SERVICE OPERATIONAL CHARACTERISTICS
4.2.9.4 COUNTER INTERFACE SERVICE QUALITIES.......+0++ 33
4.2.10 OPERATIONAL SUPPORT SERVICES .
4,2.10.1 OSS OVERVIEW...
4,2.10.2 PATHWAY'S PROPOSAL I FOR ‘Oss
4,2.10.3 OSS OPERATIONAL CHARACTERISTICS.
4,2.10.4 OSS SERVICE QUALITIES...
4.2.44 THE NETWORK INFRASTRUCTURE... anne
4,2,11.1 PATHWAY'S PROPOSAL FOR THE NETWORK INFRASTRUCTURE.
4,2,11.2 POST OFFICE LOCAL AREA NETWORK (LAN)
4,2.11.3 BRANCH WIDE AREA NETWORK (WAN) ....
4,2.11.4 CORRESPONDENCE SERVER BACKBONE NETWORK.
4,2.12 SERVICE BOUNDARIES AND INTERFACES
4,2.12.1 INTRODUCTION........
4,.2.12.2 SERVICE INTERFACES
4.2.13 PATHWAY SUPPORT SERVICES .
4.2.13.1 INTRODUCTION .
4,2,13.2 HELP DESKS .
4.2.14 SUMMARY
4.3 POCL STRATEGIC INFRASTRUCTURE SERVICE ..
4.3.1 INTRODUCTION .....seseeresceeeseseseeneereeneenee
4.3.2 SUMMARY OF POCL STRATEGIC INFRASTRUCTURE PROPOSAI
4.3.2.1 INTRODUCTION PATHWAY’S STRATEGIC INFRASTRUCTURE PROPOSAL
4.3.2.2 OVERVIEW OF THE TRANSACTION MANAGEMENT SERVICE .
4.3.2.3 OVERVIEW OF THE COUNTER INTERFACE.....+++++
4.3.2.4 OVERVIEW OF OPERATIONAL SUPPORT SERVICES.
4.3.2.5 OVERVIEW OF RIPOSTE ARCHITECTURE .........+4
4.3.3 GENERIC APPROACH
4.3.3.1 INTRODUCTION TO PATHWAYS PROPOSAL FOR A GENERIC APPROACH .
4.3.3.2 DEVELOPMENT OF THE POCL GENERIC APPROACH .........
4.3.3.3 ADVANTAGES OF THE EVOLVED POCL GENERIC APPROACH
4.3.3.4 BILL PAYMENTS.
4.3.3.5 ECCO+ REPLACE!
4,3.3.6 ENHANCED ESNS BENEFIT AGENCY SYSTEM
4.3.4 TRANSACTION MANAGEMENT SYSTEM .
4,3.4.1 INTRODUCTION TO TMS....
4.3.4.2 INTRODUCTION TO RIPOSTE .
4.3.4.3 RIPOSTE - DESKTOP......+.
4.3.4.4 RIPOSTE - SECURITY AND INTEGRI
4.3.4.5 JOURNAL SERVER..
4.3.4.6 KEY FUNCTIONS PROVIDED ‘BY JOURNAL SERVER...
4.3.4.7 CORRESPONDENCE SERVER
4.3.4.8 OPERATIONAL INTEGRITY.
4.3.4.9 RIPOSTE - UTILITIES...
4.3.4.10 VALUE ADDED PROCESSING AND INTERFACE TO CLIENT SYSTEMS.
4,3.4,11 INTERFACE TO POCL SYSTEMS us.
4.3.4.12 END TO END BILL PAYMENT SERVIC!
Pathway Response to
OJEC Notice 94/S 165-58937/EN COMMERCIAL IN-CONFIDENCE Date: 08/06/95
FUJ00098232
FUJ00098232
4.3.5 COUNTER INTERFACE.
4.3.5.1 INTRODUCTION...
4.3.5.2 BUSINESS NEEDS.
4.3.5.3 IMPLEMENTATION OF COUNTER INTERFACE - TECHNICAL
4.3.5.4 SOFTWARE ENVIRONMENT......scsssseesseceeeee
4.3.5.5 DEVELOPMENT ENVIRONMENT AND APPROACH
4.3.6 OPERATIONAL SYSTEMS SUPPORT ..
4.3.7 HARDWARE AND PERIPHERALS .
4.3.7.1 INTRODUCTION TO HARDWARE AND PERIPHERALS
4.3.7.2 TMS HARDWARE...
4.3.7.3 COUNTER INTERFACE HARDWARE ‘AND. PERIPHERAI
4.3.7.4 COUNTER INFRASTRUCTURE OPTIONS - F85 TERMINAL.
4.3.7.5 POST OFFICE BRANCH NETWORK...........
4.3.8 SATISFYING BA/POCL INFORMATION NEEDS...
4.3.9 POCL STRATEGIC INFRASTRUCTURE - SUMMAI
4.4 BENEFIT PAYMENT SERVICE
4.4.1 INTRODUCTION ......ceeeee
4.4.2 OVERVIEW OF THE BENEFIT PAYMENT SERVICE.
4.4.2.1 INTRODUCTION TO PATHWAY’S BPS PROPOSAL.
4.4.2.2 OVERVIEW OF THE CARD MANAGEMENT SERVIC!
“4.4.2.3 OVERVIEW OF THE PAYMENT AUTHORISATION SERVIC!
4.4.3 CARD MANAGEMENT SERVIC!
4.4.3.1 CMS OBJECTIVES...
4.4.3.2 CMS INFORMATION
4.4.3.3 CMS INTERFACES
4.4.4 CMS FUNCTIONS...
4.4.4.1 SUMMARY OF CMS FUNCTIONS
4.4.4.2 RECEIPT OF INSTRUCTIONS FROM CAPS.
4.4.4.3 CARDHOLDER DATA BASE. ..1++
4.4.4.4 CARD PRODUCTION AND PERSONALISATION..
4.4.4.5 CARD DESPATCH ...
4.4.4.6 CARD COLLECTION AND "ACTIVATION
4.4.4.7 LOSS, THEFT, DAMAGE AND REPLACEMENT OF CARDS
4.4.4.8 INVALIDATION AND SUSPENSION
4.4.4.9 TEMPORARY TOKEN TO SUPPORT
4,4,4,10 CARD MANAGEMENT ENQUIRIES AND INFORMATION NEED:
4,4,4,11 CHANGE NOMINATED OFFICE...
4.4,4.12 CATERING FOR SPECIAL NEEDS ‘GROUPS.
4.4.4.13 CARD MANAGEMENT HELP DESK........
4.4.5 CARD-BASED BENEFIT PAYMENT PROCESS
4.4.5.1 INTRODUCTION TO CARD BASED BPS....
4,4,5.2 PAYMENT AUTHORISATION SERVICE (PAS)
4.4.5.3 RECEIPT OF AUTHORISED PAYMENTS FROM CAPS.
4.4.5.4 DISTRIBUTING DATA TO THE POINT OF ENCASHMENT,
4.4.5.5 APPLYING PAYMENT AND CARD STOPS .
4.4.5.6 CARD AUTHENTICATION AND CARDHOLDER VERI
4.4.5.7 IDENTIFICATION OF BENEFITS PAYABLE ..
4.4.5.8 RECEIPTS...
4.4.5.9 STATEMENT:
Pathway Response to
OJEC Notice 94/S 165-58937/EN COMMERCIAL IN-CONFIDENCE Date: 08/06/95
FUJ00098232
FUJ00098232
4.4,5.10 EXCEPTION PROCESSING..
4,4.5.11 NOTIFICATION OF ENCASHMENT ‘AND “EXPIRY TO CAP
4,4,5,12 NOTIFICATION OF EXCEPTIONAL CARD USAG
4.4,5.13 AUDIT TRAILS... ”
4.4,.5.14 BENEFIT AGENCY ENQUIRIES
4,4,5.15 SECURITY. esssseseeeeees
4,4,5.16 COUNTERFEIT CARDS
4,4,.5.17 RECONCILIATION......
4,4.5.18 PHYSICAL ATTRIBUTES OF PAS
4.4.6 THE MIGRATION OF THE BA CARD...
4 4.6.3 PATHWAY'S EXPERIENCE IN SMART CARDS
4.4.6.4 PATHWAY SMART CARD REFERENCES.
4.4.7 CUSTOMER ACCEPTABILITY ..
4.4.7.1 INTRODUCTION TO RESEARC!
4.4.7.2 BACKGROUND ATTITUDES..
4.4.7.3 OPINION FORMERS.......
4.4.7.4 ATTITUDES TO BENEFIT COLLECTIONS .
4.4.7.5 SAFETY, SECURITY & FRAUD .
4.4.7.6 RESEARCH RECOMMENDATIONS.
4.4.8 CONFIGURATION MANAGEMENT..
4.4.8.1 INTRODUCTION TO CONFIGURATION MANAGEMENT
4.4.8.2 PATHWAY SERVICE MANAGEMENT
4.4.8.4 SECURITY KEY DISTRIBUTION
4.4.9 REQUIRED DEVELOPMENT...
4.4.10 SUMMARY OF BENEFIT PAYMENT PROPOSAL.
4.5 SPECIFIC RESPONSES
GENERAL... _
EQUIPMENT CONSIDERATIONS
BENEFIT PAYMENTS SYSTEM GENERAL.
BENEFIT PAYMENTS SHOULD BE MADE
TOKEN PRODUCTION, ISSUE AND REPLACEMENT
4.6 VERIFICATION OF BA AND POCL FUNCTIONAL OBJECTIVES ...s:sssccsscessseesrssenneeetees L
Pathway Response to
OJEC Notice 94/S 165-58937/EN COMMERCIAL IN-CONFIDENCE Date: 08/06/95
5 STEADY STATE SERVICES
5.1 INTRODUCTION.
5.1.4 STRUCTURE O!
5.1.2 APPROACH TO SERVICE DEVELOPMENT AND INTRODUCTION
5.1.3 SERVICE DELIVERY ORGANISATION ....
5.2 THE POCL STRATEGIC INFRASTRUCTUR!
5.2.1 INTRODUCTION ....sesseccseeeseereeseeeessenanenes
5.2.2 SERVICE DEVELOPMENT AND INTRODUCTION
5.2.3 STRATEGIC INFRASTRUCTURE SERVICE OPERATION FROM THE USER PERSPECTIVE
al
524 ‘SERVICE “PERFORMANCE. . 8
5.2.5 BA/POCL RESPONSIBILITIES . 9
5.3 BENEFIT PAYMENT SERVICE 9
5.3.1 INTRODUCTION ......sceeeseee 9
5.3.2 SERVICE DEVELOPMENT AND INTRODUCTION . 10
5.3.3 BPS OPERATION FROM THE USER PERSPECTIVE . 44
5.3.4 SERVICE PERFORMANCE...... 13
5.3.5 BA/POCL RESPONSIBILITIES . 13
5.4 SUPPORT SERVICES .. 14
5.4.1 INTRODUCTION .. 14
5.4.2 HELP DESK CALL RECEPTION AND CALL TRACKING. 14
5.4.3 SPECIALIST HELP DESKS .......... 16
5.4.4 UNDERLYING SUPPORT SERVICE 18
5.4.5 USER PERSPECTIVE 19
5.4.6 PERFORMANCE..... 20
5.4.7 CONTRACTING AUTHORITIES RESPONSIBILITIES. 21
22
22
22
24
24
25
25
25
26
29
29
29
30
33
5.5 POTENTIAL DISASTER SCENARIOS .
5.5.1 INTRODUCTION .........
5.5.2 COUNTER SYSTEM FAILURE (X1 &
5.5.3 TMS SYSTEM FAILURE (X3) .....
5.5.4 BPS SYSTEM FAILURE (X4 & X5).
5.5.5 NETWORK FAILURE (X6 & X7) .
5.6 CONTRACT MANAGEMENT SERVIC!
5.6.1 INTRODUCTION AND OVERALL APPROACH.
5.6.2 SCOPE OF THE CONTRACT MANAGEMENT FUNCTION .
5.6.3 A VIEW FROM THE USER'S PERSPECTIVE......2+++s++0
5.7 CONTRACT TRANSFER SERVICE
5.7.1 OVERVIEW...
5.7.2 PARAMETERS. FOR CONTRACT TRANSFER
5.8 SPECIFIC RESPONSES
Pathway Response to
OJEC Notice 94/S 165-58937/EN. COMMERCIAL IN-CONFIDENCE Date: 08/06/95
FUJ00098232
FUJ00098232
TABLE OF CONTENTS
6. PILGT PROGRAMME
6.1 INTRODUCTION ..
6.2 PROVING APPROAC!
6.2.4 BACKGROUND ....
6.2.2 PROVING PROCESS
6.2.3 PROVING MODEL.
6.2.4 PROVING TECHNIQ!
6.2.5 BUSINESS PROCESS PROVING
6.2.6 SERVICE CHARACTERISTICS PROVING
6.2.7 TECHNICAL STRATEGY PROVING ..... 13
6.2.8 WORKING RELATIONSHIPS
6.2.9 RISK MANAGEMENT .....
6.3. DEMONSTRATOR PHASE
6.3.1 INTRODUCTION .........
6.3.2 DEMONSTRATION MODEL .
6.3.3 DEMONSTRATOR PHASE CHECKPOI
6.3.4 PROPOSAL BASELINE
6.3.5 AGREED BASELINE....
6.4. OPERATIONAL TRIAL PHASE
6.4.1 INTRODUCTION ........0045
6.4.2 OPERATIONAL TRIAL MODEL.
6.4.3 OPERATIONAL TRIAL PHASE CHECKPOINTS
6.4.4 CONTRACTUAL BASELINE . eenenosse
6.4.5 FINAL ACCEPTANCE......
6.5. PILOT PROGRAMME PROVING
6.5.1 INTRODUCTION ........-e00+6
6.5.2 OVERALL PRIME CONTRACTOR CAPABILITY.
6.5.3 POCL PRIME NEEDS...
6.5.4 BENEFIT AGENCY PRIME NEEDS .
6.5.5 CUSTOMER / CLERK NEEDS ..
6.5.6 TRAINING AND DOCUMENTATION
6.5.7 SERVICE DELIVERY
6.5.8 IT INFRASTRUCTURI
6.6. PILOT PROJECT PLAN:
6.6.1 INTRODUCTION .....
6.6.2 MANAGEMENT STRUCTURE .
6.6.3 DELIVERABLES...
6.6.4 PILOT PROJECT ..
6.6.5 STAGE 1 BUSINESS PROCESS PROVING
6.6.6 STAGE 2 SERVICE CHARACTERISTICS PROVING
6.6.7 STAGE 3 TECHNICAL ARCHITECTURE PROVING
6.6.8 RESOURCING...
6.6.9 RESOURCE DEPENDENCIES:
6.6.10 COVERAGE MATRIX.
6.7 SUMMARY .
6.8. SPECIFIC RESPONSES.
Pathway Response to
OJEC Notice 94/S 165-58937/EN COMMERCIAL IN-CONFIDENCE Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
TABLE OF CONTENTS
7. ROLL-OUT & IMPLEMENTATION.
7.1 INTRODUCTION ..
7.2 BUSINESS IMPERATIV!
7.2.2 POCL BUSINESS IMPERATIVES
7.2.3 BA BUSINESS IMPERATIVES...
7.2.4 PATHWAY’S BUSINESS IMPERATIVES
7.3 ROLL-OUT PROGRAMME.
7.3.1 INTRODUCTION
7.3.2 GEOGRAPHY...
7.3.3 FUNCTIONALITY,
7.3.4 CARD DISTRIBUTI
7.3.5 RISK MANAGEMENT ..
7.3.6 PATHWAY FAST-TRACK PROGRAMME
7.3.7 FAST-TRACK OUTLINE PLAI
7.4 ROLL-OUT SERVICES..
7.4,1 SCOPE OF SERVICES.
7.4.2 OVERVIEW......ss0008
7.4.3 MANAGEMENT OF CHANGE.
7.4.4 ROLL-OUT MANAGEMENT.
7.4.5 VERIFICATION ........+++
7.4.6 SUPPLY MANAGEMENT .
7.4.7 HELP DESK........
7.4.8 SITE PREPARATION
7.4.9 SYSTEM BUILD
7.4.10 TRAINING .....
7.4.11 DELIVERY & INSTALLATION
7.5 EXPERIENCE & CAPABILITY.....
7.5.1 ROLL-OUT ORGANISATION & MANAGEMENT ..
7.5.2 EXPERIENCE AND CAPABILITIES
7.6 SUMMARY .....00000
SPECIFIC RESPONSES
DAOONNARWWERRBE
Pathway Response to
OJEC Notice 94/S 165-58937/EN COMMERCIAL IN-CONFIDENCE Date: 08/06/95
FUJ00098232
FUJ00098232
8. COMMERCIAL POLICIES AND RELATIONSHIPS
8.1 INTRODUCTION .
8.2 COMMERCIAL PRINCIPL!
8.2.1 THE VALUE-FOR-MONEY PRINCIPLE
8.2.2 SERVICE INTEGRITY
8.2.3 CHARGING STRUCTURE:
8.2.4 ADDING FURTHER APPLICA
8.2.5 USE OF FACILITIES .......
8.2.6 GOVERNMENT POLICIES.
8.3 CONTRACTUAL MODELS...
8.3.1 PFl COMPARED WITH A CONVENTIONAL PROCUREMENT
8.3.2 CONTRACT STRUCTURES......:seseeeseeee
8.3.3 SUPPLY OF SERVICES UNDER THE PFI 12
8.3.3.3 BUSINESS DEVELOPMENT PARTNERSHIP . 14
8.3.4 FUNDING OF SERVICES PROVIDED. .21
8.3.5 CHARGES UNDER PFI - FRAMEWORK .21
8.3.6 RISK MANAGEMENT AND RISK TRANSFER 30
8.3.7 THE CONVENTIONAL PROCUREMENT OPTION .. 38
8.4 INTELLECTUAL PROPERTY RIGHTS AND DATA OWNERSHIP
8.5 RE-TENDERING, RESIDUAL VALUES AND TRANSFER OF ASSET.
8.6 EARLY TERMINATION OF CONTRACT
8.7 SUMMARY
Pathway Response to
OJEC Notice 94/S 165-58937/EN COMMERCIAL IN-CONFIDENCE Date: 08/06/95
TABLE OF CONTENTS
ANNEX 1 ADDITIONAL FINANCIAL INFORMATION
4) ALLIANCE & LEICESTER ANNUAL ACCOUNTS
1994
1993
1992
2) BRITISH TELECOMM ANNUAL ACCOUNTS
1994
1993
1992
ANNEX 2
2. PATHWAY QUALITY POLICY.
2.3 CONTINUOUS IMPROVEMENT...
2.4 QUALITY MANAGEMENT SYSTEM DOCUMENTATIO
ANNEX 3
3. CASH MANAGEMENT AND POST OFFICE RECONCILIATION
3.1 CASH MANAGEMENT...
3.2 POST OFFICE RECONC!
3.3 CLIENT/POCL RECONCILIATION....
ANNEX 4
4 BASELINE PROPOSAL SUMMARY AND OPTIONS .
4.1 INTRODUCTION
4.2 SERVICES........
4.3 HARDWARE, SOFTWARE AND APPLICATIONS.
4.4 REDUCED COST STRATEGIC INFRASTRUCTURE.
4.5 PRODUCT DESCRIPTIONS
CnwWRE
Pathway Response to
OJEC Notice 94/S 165-58937/EN COMMERCIAL IN-CONFIDENCE Date: 08/06/95
FUJ00098232
FUJ00098232
TABLE OF CONTENTS
ANNEX 5
5. PATHWAY SECURITY POLICY AND APPROACH
5.1 INTRODUCTION .......cssssssenesssrennscnenseneenennensnnaneene
5.2 OBJECTIVES.........
5.3 RESPONSIBILITIES.
5.4 PATHWAY SECURITY STANDARDS.
5.5 THE PATHWAY APPROACH TO SECURITY,
5.6 THREATS .....
5.7 CONTROLS...
OhWONEBBBE
ANNEX 6 PATHWAY CASE STUDIES
6.1 MINISTRY OF DEFENCE CHOTS PROJECT.
6.2 ITIN ICL - MAJOR CHANGE PROGRAM.....
6.3 INLAND REVENUE - SERVICE MANAGEMENT CENTRE
6.4 CAMELOT......cssscssessssscsensnsssnsssonseseesensesersnenersasenennearsn
6.5 ALPS - ESNS (AUTOMATION OF LONDON POST OFFICES)
6.6 POSTBANK (GERMANY)
6.7 BA PROJECT...
6.8 VISA CALL CENTRE
6.9 ALLIANCE ACCOUNT...
6.10 GIROBANK - LEGAL INTEGRATION.
6.11 BRITISH GAS BILL PAYMENT SERVICE
6.12 AN POST COUNTERACTION CASE STUD’
6.13 VICTORIA WINE...
6.14 J SAINSBURY - TOTAL MANAGED SERVICE..
6.15 CARDLINK (IRELAND)..........++
6.16 DE LA RUE CARD TECHNOLOGY.
BHaSRoNaeE
ANNEX 7 CURRICULUM VITAE AND ROLE DESCRIPTIONS
ANNEX 8
8. RESEARCH PROGRAMMES
8.1 INTRODUCTION .
8.2 DISCUSSIONS WITH VOLUNTARY ORGANISATI
SECTIONS OF THE BENEFIT-RECIPIENT COMMUNITY
8.3 BENEFIT CARD.
Pathway Response to
OJEC Notice 94/S 165-58937/EN COMMERCIAL IN-CONFIDENCE Date: 08/06/95
FUJ00098232
FUJ00098232
TABLE OF CONTENTS
ANNEX 9
9. TECHNOLOGY TRENDS
9.1 FRAUD REDUCTION
9.2 CARD TECHNOLOGY (
9.3 THE MIGRATION PATH
9.4 PATHWAY’S PROPOSED MIGRATION STRATEGY ..
ANNEX 10 GLOSSARY OF TERMS
Pathway Response to
OJEC Notice 94/S 165-58937/EN COMMERCIAL IN-CONFIDENCE Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 2 - INTRODUCTION
SECTION2 TABLE OF CONTENTS
2. INTRODUCTION....
2.1 STRUCTURE OF THE PATHWAY PROPOSA\
2.2 SSR CHAPTER 9....
2.3 POINT OF CONTACT
2.4 NAVIGATING THE PATHWAY PROPOSAL
2.5 GLOSSARY OF TERMS.....
2.6 PATHWAY TERMINOLOGY .
2.6.1 IDENTIFICATION (CUSTOMER IDENTIFICATION)
2.6.2 VERIFICATION (CUSTOMER VERIFICATION)...
2.6.3 AUTHENTICATION (CARD AUTHENTICATION).
2.6.4 AUTHORISATION (PAYMENT AUTHORISATION).
PAHRAWANEEE EF
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 2 - INTRODUCTION
2. INTRODUCTION
We have pleasure in presenting our proposal in response to the Statement of
Service Requirements for the BA/POCL Programme : Bringing Technology to the
Post Office and Benefit Payments.
2.1 STRUCTURE OF THE PATHWAY PROPOSAL
2.11 This proposal has been designed to assist the evaluators in their task. To this
end, the proposal meets the requirements outlined in Chapter 9 of the SSR,
concerning the structure of the response.
2.1.2 Where Pathway believes that supplementary information could be useful in
support of the proposal this is referenced within the main response and is
provided separately in the form of annexes, within the Supplementary
Information Volume.
2.2 SSR CHAPTER 9
Pathway confirms that it understands and accepts the statements made within
Chapter 9.
2.3 POINT OF CONTACT
2.3.1 The point of contact within Pathway for all communications is :
Primary : Martin Johnston
Pathway Group Limited
Forest Road
Feltham
Middlesex
TW13 7EJ
Telephone ~~ 1
Fax
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 4
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 2 - INTRODUCTION
2.3.2
2.4
2.4.1
2.4.1.1
2.4.2
Deputy : John Bennett
Pathway Group Limited
Forest Road
Feltham
Middlesex
TW13 7EJ
Telephone
Fax
Should you have any queries please do not hesitate to contact Pathway on the
above numbers.
NAVIGATING THE PATHWAY PROPOSAL
The Pathway proposal has been provided within its own slipcase. The slipcase
contains 4 folders that are detailed below :
* Folder 1 Management Summary. This is a spiral-bound document contained
within a folder that summarises the Pathway Service.
+ Folder 2 Main Response. This folder details Pathway’s response to the
Introduction, The Service Provider, The Services and Systems Architecture,
Steady State Services, The Pilot Programme and the Roll-out Programme.
¢ Folder 3 Commercial Response. This folder contains Pathway’s response for
the Commercial requirements. It has been supplied within a separate folder
in accordance with the requirements of BA/POCL.
¢ Folders 4 Supplementary Information. This folder contains the annexes
identified throughout the other sections of the proposal.
Pathway has provided 16 copies of the proposal with one copy provided on
floppy disk, plus a single sealed envelope containing information that has been
kept separate from the main proposal, meeting the requirements of BA/POCL.
A diagram depicting the Pathway Proposal has been provided in Fig. 1 on the
next page, as a navigation tool.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 4
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 2 - INTRODUCTION
2.5.1
Fig. 1 - The Pathway Proposal in its Slipcase
GLOSSARY OF TERMS
To assist in the clarity of understanding of the Pathway proposal, a Glossary of
Terms is given in Annex 10.
To assist the reader we have also provided a Pathway Bookmark reference card
which contains a sub-set of the Glossary of Terms. Copies of the Pathway
Bookmark have been included in the Main Response, the Commercial Response
and in the Supplementary Information folders.
PATHWAY TERMINOLOGY
To avoid confusion Pathway has provided descriptions for four terms used
specifically throughout the proposal when discussing the process of authorising
benefit payments, These are Identification, Verification, Authentication and
Authorisation.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 4
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 2 - INTRODUCTION
2.6.1 IDENTIFICATION (CUSTOMER IDENTIFICATION)
2.6.1.1 This term is used when identifying the cardholder to the system, which is done
by swiping the card or keying in the card number. It identifies the benefit
entitlement and personal details of the cardholder by using the card number to
retrieve information from various Pathway systems.
2.6.2 VERIFICATION (CUSTOMER VERIFICATION)
2.6.2.1 This term describes the process of ensuring that the cardholder (the person
presenting the card) is who he says he is. Customer verification methods
include signature, PIN, biometrics and photocards.
2.6.3 AUTHENTICATION (CARD AUTHENTICATION)
2.6.3.1 Authentication is the process that determines whether the card or foil is valid
(not forged). This is done partly by inspection and partly by checking the
validity of data held on the card, such as the issue number. (This term can be
used in a wider sense to mean the process that verifies the identity of any entity.
In this document, however, the previous definition is used).
2.6.4 AUTHORISATION (PAYMENT AUTHORISATION)
2.6.4.1 Authorisation is largely an automatic process assuming all other parts of the
process have been passed. It consists of checking that the payment is being
made at the right place and the right time.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 4
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 3 - THE SERVICE PROVIDER
SECTION 3 TABLE OF CONTENTS
3. THE SERVICE PROVIDER .
3.1 INTRODUCTION..........++
3.2 PATHWAY THE COMPANY ..
3.3 THE SERVICE PROVISION..
3.3.1 INTRODUCTION TO SERVICE PROVISIO!
3.3.2 SERVICE ELEMENTS
3.3.3 SERVICE CREATION
3.3.4 SERVICE PROVING.
3.3.5 SERVICE IMPLEME
3.3.6 SERVICE DELIVERY..
3.3.7 SERVICE TRANSFER.
3.4 BUSINESS DEVELOPMENT AND RELATIONSHIPS..
3.4.1 INTRODUCTION TO BUSINESS DEVELOPMENT AND RELATIONSHIPS .
3.4.2 POCL’S STRENGTHS .....sesccsssseseesseesseeeessensnneeseenennsase
3.4.3 PATHWAY’S STRENGTHS IN BUSINESS DEVELOPMENT
3.5 FINANCIAL INFORMATION
i wii
BROGBBBESS0nmNNbPe
Pathway Response to COMMERCIAL IN-
OJEC Notice 94/S 165-58937/EN CONFIDENCE Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 3 - THE SERVICE PROVIDER
3.2
3.2.1
3.2.2
3.2.3
THE SERVICE PROVIDER
INTRODUCTION
The purpose of Section 3 is to explain the make-up of Pathway and discuss how
we will deliver the range of proposed services and engender a stable long-term
business relationship with BA/POCL, Where appropriate, we will identify the
separate contributions and responsibilities of each of our member organisations.
However, Pathway will carry full responsibility for delivery of the service and
will be the prime interface to BA/POCL during the life of the contract.
We will cross-reference where appropriate to other sections of the proposal
where a particular subject is covered in more detail.
We believe that all the financial information requested has been provided in this
proposal or previously with the Statement of Capability.
PATHWAY THE COMPANY
Pathway has been set up with a clear purpose : to respond to the Statement of
Service Requirement (SSR) and to develop and deliver the service to the Benefit
Agency and Post Office Counters Ltd. Pathway’s shareholders have been
carefully chosen to bring together complimentary providing full coverage of
skills the BA/POCL service requirement. Both to avoid overlap and to ensure
full coverage of the service requirement.
Pathway has been registered as a private company with three shareholders, all of
whom are world leaders in their respective fields of expertise and who share the
common goal of developing a long-term business relationship with BA/POCL :
De La Rue - the world’s leading banknote and security printer, using integrated
cash handling equipment and electronic payment solutions. De La Rue is the
leading UK supplier of payment cards and cheques, including manufacture,
personalisation and distribution.
ICL - a leader in the field of major systems integration services, project
management of complex projects and supply of world-class technology.
Girobank - leaders in the field of cash management and reconciliation providing
innovative financial services to the corporate sector.
PATHWAY BOARD
The Pathway board has been set up under the chairmanship of Sir Michael
Butler with board representatives from the shareholders and principal
subcontractors.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 3 - THE SERVICE PROVIDER
4
Sit Michael Butler I
Chairman I
I -puty
I Chairman J. White 5.5. Jones T-Reynolds JAH, Rennese Pathway
LK. Todd De La Rue Girobank An Post Manaving De Directors
ICL naging Director
Fig 1 - The Pathway Shareholders’ Board
3.2.4 Pathway will be responsible for these services :
* Overall Project Management
* Secure Service Delivery
* Application Design and Business Planning
¢ Risk Management
* Business and Marketing Development and Business Consultancy
PATHWAY’S SUBCONTRACTORS
3.2.5 Pathway has also set up a number of subcontract relationships that bring very
specific and vital expertise to the project. All of these have been key
contributors to this proposal and therefore have established a common culture
within Pathway and have developed excellent working relationships :
An Post - the Irish Post Office who are already well advanced in the
implementation of technology to improve their services
to the public. Over the past two years, An Post has
installed systems in over 400 offices. Systems installed so
far include those for the payment of benefits, receipts of
savings and a variety of counter services, all with full end-
of-day reconciliation. User acceptance has proved to be
very high. An Post has set up processes and procedures
for their offices, Pathway will build on that expertise and
ensure that the lessons and the experiences are reflected
in our solution.
Escher Group - the principal designers and developers of the An Post
systems and already recognised by Microsoft as world
leaders in the design of intuitive counter systems. Escher
has also developed the very successful ESNS system in the
ALPS project which is already rolled out to over 500
offices in the London area. Escher has the major benefit
of developing post office systems for over five years.
This experience will be invaluable in the design of
systems for BA/POCL.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
iw:
SECTION 3 - THE SERVICE PROVIDER
British Telecom -
Hambros Bank -
the UK’s leader in network design, provision and
management.
expertise in PFI advice and commercial advice in general.
Alliance & Leicester - card and payment management expertise.
3.2.6 In summary, the Pathway service will be delivered as follows :
This company :
Will provide these services :
ICL
* Systems Integration
¢ Retail Systems Consultancy
¢ Business Process Re-engineering
* Roll-out capability
* Nationwide Support
¢ Technology
* Large Scale Project Management
De La Rue Group
* Magnetic and Smart Card Manufacture and
Distribution
* Secure Printing and Identity Card Systems
* Card Technology
¢ Cash Management
Girobank Plc
¢ Business Development
¢ Fraud Risk Management
¢ Reconciliation and Accounting Management
Alliance & Leicester
* Card Management
* Payment Management
An Post & Escher
* Post Office Counter Automation
¢ Network Software and Consultancy
British Telecom
* Network Design, Provision and Management
Hambros Bank Plc ¢ PFI Expertise
¢ Commercial Structure and Advice
¢ Risk Assessment
¢ Financial System Security
* Corporate Finance Best Practice
PATHWAY TEAM
3.2.7 The Pathway team is in place. The management structure has been agreed and
the positions filled. The structure of the team is as follows :
Pathway Response to
OJEC Notice 94/S 16S-58937/EN
COMMERCIAL IN-CONFIDENCE
Page: 3 of 16
Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 3 - THE SERVICE PROVIDER
Managing Director
Pathway
JH BENNETT
Bid Team
JAJONES
{ [ i i f 1
Director, Director, Quality & Director Director Director I Director
I Commercial & Finance Risk Management Business Development Technical Programmes Operations
i AE OPPENHEIM MH BENNEIT S$] HODGKINS JCCDICKS MJ BCOOMBS SM ROWE
Fig, 2 - The Pathway Management Board
Title and Appointee Principal Responsibilities
Managing Director Ensure fulfilment of contract
John Bennett Establish strategic direction
Director - Commercial & Finance Manage commercial, legal and
Tony Oppenheim financial aspects of Pathway
Director - Quality & Risk Management I Manage all risks
Martyn Bennett Ensure Quality adherence
Director - Business Development Generate new business for
Stephen Hodgkins POCL and Pathway
Director - Technical Design, development and
John Dicks testing of overall solution
Director - Programmes Ensure delivery of end-to-end
Mike Coombs solution
Director - Operations Operation of services in line
Stephen Rowe with
service level agreements
3.2.8 Full details of roles and responsibilities as well as personal CVs are included in
Annex 7.
3.2.9 Each Director is responsible for managing and resourcing his area of
responsibility. He will manage either Pathway’s own staff or. specific
subcontractors to undertake tasks within the project. To ensure best value for
money in relation to any service or product, Pathway will undertake rigorous
evaluation of suppliers, at all times aiming for ‘best of breed’ wherever possible.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 3 - THE SERVICE PROVIDER
PATHWAY CONTRACT STRUCTURE
3.2.10 Pathway will provide BA/POCL with a single interface to manage the
implementation and running of the service as shown in the following diagram :
ven Moc; I Contracting
BA PocL Authorities
ICL ; Girobank I Shareholders
BT &
/ Escher Leicester ;
/ ICL Girobank
WA DeLaRue An Post Alliance ~\ Subcontractors
Fig. 3 - Pathway Contract Structure
3.2.11 The overall structure, which has been built at every level from the valuable
skills, capabilities and experience of the organisations forming Pathway Group
Ltd, is designed to provide the greatest flexibility combined with a very flat
hierarchy to minimise costs and ensure effective and fluent communications.
DESIGN AND DEVELOPMENT
3.2.12 Our design and development teams are already identified and our development
of demonstration/prototype systems is well under way. Our approach has been
firstly to understand the requirements of the BA/POCL business and then to
respond in a business oriented way to ensure that our solution best delivers the
benefits required by the Contracting Authorities.
3.2.13 The three aspects of Pathway’s service provision that are key to our joint success
are Quality, Management of Change and Risk Management. Pathway embraces
these three qualities in its ethos.
QUALITY
3.2.14 Pathway considers that quality of service and continuous improvement is
fundamental to its success in meeting or exceeding BA and POCL expectations.
As a hub to its Quality Management, Pathway has adopted the Strategic Quality
Model, see Fig. 4. Each element of the model will be used as a criterion for
measuring Pathway’s progress towards full quality management.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ie
=> People =>
Satisfaction
Customer =a
Satisfaction
Leadership
Processes
Business Results
Impact on I
Resources => se Seeelty u>
—- ENABLERS ~~~
Fig. 4 - The Nine Elements of the Strategic Quality Model
3.2.15 This will be lead by the management team with the primary objectives of :
* Implementing quality processes
* Gaining IS09001 accreditation
¢ Developing a culture of continuous improvement
¢ Assuring subcontractor quality
¢ Delivering customer satisfaction
3.2.16 The philosophy of best in class quality management is underpinned by the
success of member organisations, all of which are either accredited for their
quality systems or are in the process of achieving it. For example, Girobank was
the first UK financial services company to achieve IS09001, and ICL won the
European Quality Award in 1994.
MANAGEMENT OF CHANGE
3.2.17 Critical to the success of a programme of this magnitude are the skills with
which the services are introduced to POCL, its clients, staff and agents as well as
to BA and its customers and staff. These skills are essential throughout the life
of the programme as it evolves to incorporate new clients, services and
legislation. Pathway’s plans incorporate these requirements for management of
change in the following way :
* Roll-out of the system will be preceded by a comprehensive sequence of
public awareness events
* Core processes have been driven by and will react to BA and POCL needs
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
Shs 5m
SECTION 3 - THE SERVICE PROVIDER
3.2.18
3.2.19
3.2.20
3.2.21
3.2.22
3.3
3.3.1
3.3.1.1
The members of Pathway’s management team have all experienced substantial
change within their previous organisations, and therefore have experience of
change management. For example, Girobank has moved from the public to the
private sector and integrated its entire personal customer account base with the
Alliance & Leicester; ICL has completely re-structured its European operations
to improve its responsiveness and competitiveness, and De La Rue has created a
new organisation which recognises the growth of electronic payment systems.
This combination of focus on the customer, continuous improvement,
management of change and flexibility ensures delivery by Pathway of the highest
quality of service to BA, POCL and its clients, customers, staff and agents.
RISK MANAGEMENT
The identification, evaluation and prioritisation of risks and the development
and implementation of mitigation plans form a critical input to all phases of
development and running of the Pathway service. Responsibility for the risk
management process is assigned to the Director - Quality and Risk Management.
A risk register has been established; each risk is assigned an owner at Director
level, whose responsibility is to manage the risk by :
(i) Proof (for example through demonstrations, modelling, analogy or
reference)
(ii) Changing the system or subcontractor
(iii) Assigning the risk to the organisation best able to manage it, including BA,
POCL or subcontractor
(iv) Using additional resources (for example, more skills in a particular area)
The risk register will be constantly updated. Where we are advised of Pathway
risks on the BA/POCL register, they will be matched or added. The
management team will review the risk register regularly, highlight the most
critical and take steps to eliminate them.
THE SERVICE PROVISION
INTRODUCTION TO SERVICE PROVISION
Our purpose in this section is to explain how Pathway will provide the services
required by BA/POCL. We will cover this under the following headings :
Service Elements - the main services to be offered
Service Creation - the design, financing and build
Service Proving - demonstration, pilot and risk management
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 7 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 3 - THE SERVICE PROVIDER
Service Implementation _- transition, integration and roll-out
Service Delivery - steady state and operation
Service Transfer - end of service life approach
3.3.2 SERVICE ELEMENTS
3.3.2.1 BENEFIT PAYMENT SERVICE
3.3.2.1.1 Pathway will provide a Benefit Payment Service (BPS) which meets the
objectives stated in the SSR. The BPS will :
« Eliminate existing paper-based methods of payment
¢ Offer full security, auditability and reconciliation
* Meet BA’s critical success factors
¢ Fully support the needs for end-to-end management of payment
« Guarantee to make the right payment to the right person at the right time
3.3.2.1.2 Pathway will provide the full operational service. We will employ the services
of our shareholder companies to provide the following under subcontract :
* De La Rue for magnetic and/or smart card supply, personalisation and
distribution
* ICL for TMS and Counter Interface elements
¢ Girobank for provision of Card and Payment Management Services
3.3.2.1.3 This proposed service will meet the business requirement of BA/POCL. Full
details of the service and the Pathway approach will be found in Section 4.4.
3.3.2.2 POCL STRATEGIC INFRASTRUCTURE SERVICE
3.3.2.2.1 Pathway will provide a Strategic Infrastructure Service to enable POCL to
automate all transactions at the counter. This approach is underpinned by
industry-standard technology architecture at every counter position backed-up
by high-quality systems providing the management information to allow POCL
to both improve the current services to the public and to build new services.
3.3.2.2.2 Pathway will employ a unique distributed architecture which will combine a
high-availability solution with automatic back-up and full resilience. The system
will ensure fast counter transactions with minimum counter waiting time.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 8 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
3.3.2.2.3 We aim to interface easily to all POCL client systems either on-line or in batch
mode using appropriate software agents. We recognise that the management
information needs of POCL will evolve during the course of the procurement
and we will ensure that our approach has the flexibility to cope with this
change.
3.3.2.2.4 Pathway will automate existing counter products in such a manner as to allow
the take-on of new business rapidly, easily and readily.
3.3.2.2.5 More detail on the POCL Strategic Infrastructure Service will be found in
Section 4.3.
3.3.3 SERVICE CREATION
3.3.3.1 Based on our understanding of the business needs of BA/POCL, Pathway has
placed particular emphasis on matching our architectural solution to these
needs. We wish to ensure that at all times, the business drives the architecture,
not the other way round.
3.3.3.2 We will provide a service to BA/POCL that :
¢ Enhances the image and raises the level of the service
* Recognises the importance of the counter as the focal point of service
delivery
¢ Automates the business processes cost effectively and efficiently
3.3.3.3 Pathway has ensured that it has employed the capabilities, skills and experience
to design, build, finance and operate the service over the life of the contract.
3.3.3.4 We have analysed the requirements, evaluated different options to ensure that
our proposed solution takes account of existing product sets and minimises the
risks inherent in the development of new systems.
3.3.3.5 We have carefully evaluated the finance options and taken advice from
Hambros, our financial advisors, and we fully endorse the PFI approach.
Pathway’s total approach can be characterised as ensuring a service that gives :
* Optimum service availability
* Cost-effective service
¢ Full security and resilience
* Rapid development and implementation
3.3.3.6 Full details on our specific design approach and details of the Pathway solution
can be found in Section 4.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 9 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ec
SECTION 3 - THE SERVICE PROVIDER
3.3.4
3.3.4.1
3.3.4.2
3.3.4.3
3.3.4.4
3.3.4.5
3.3.5
3.3.5.1
3.3.5.2
3.3.5.3
3.3.5.4
SERVICE PROVING
Pathway understands that for a project of this size, proving of the solution is
imperative and will lead to increased user confidence that the service really will
deliver the key benefits in the required timescales.
We will undertake this proving exercise using all of the following :
* Demonstrations of existing products where relevant
* Case studies
* Reference visits
* Specific demonstrations prepared for this service
¢ Prototyping
* Operational pilot systems
These approaches will ensure that we demonstrate existing cases of relevant
activity and also that we work closely in partnership with BA/POCL to develop
the solution in an interactive way to ensure full adherence to the requirements.
During the proving period, we will also continue to evaluate and thus minimise
risk, Our overall aim is to deliver a quality service in a cost-effective and timely
manner.
The Pathway approach to proving of the service is detailed in Section 6.
SERVICE IMPLEMENTATION
The Pathway approach to roll-out and implementation has concentrated on the
best way of delivering business benefit to BA/POCL in the fastest timescale.
Within this approach, we have paid particular attention to ensuring control of
risk and adopting a cost-effective approach.
We are recommending a fast-track approach which builds on existing solutions
where possible. We will modify these solutions to ensure a fit with the
BA/POCL requirement. We will implement the solution on industry-standard
hardware in a modular fashion, thus taking advantage of open standards.
The Pathway roll-out plan, Stage 1, will first build on the already successful
ESNS systems within the ALPS project. Pathway’s experience in high-volume
roll-outs in short timescales in the retail environment, such as Sainsbury and
Marks & Spencer and in Government projects such as CHOTS, will ensure that
the implementation plans are secure. This experience will ensure that we
understand the risks and manage them. Further, the infrastructure necessary to
handle such a roll-out is already in place.
Secondly, we will take advantage of the excellent systems already running in An
Post. Pathway does recognise and understand the different scales of the two
environments and will prove conclusively that scalability is assured.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 10 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 3 - THE SERVICE PROVIDER
3.3.5.5
3.3.5.6
3.3.6
3.3.6.1
3.3.6.2
Stage 2 of the implementation plan will offer the complete Card Management
Service while Stage 3 will see the implementation of Payment Management and
positive authorisation.
Full details of Pathway’s implementation and roll-out strategy will be found in
Section 7.
SERVICE DELIVERY
Pathway will put in place a professional experienced team to manage the day-to-
day operation of the service. This team will come under the control of the
Director - Operations and principally cover three main areas :
* Client Interfaces
¢ BA/POCL interfaces
¢ Day-to-day operation management
We will provide the services to BA/POCL on the basis of the following
principles :
* Service excellence
* Client and customer requirements focus
« End-to-end performance measures
¢ Service level agreements
* Clear contractual commitments with penalties for non-performance
* Bias for action
¢ Continuous improvement
* Priority to identify and bring on new revenue streams
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 11 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 3 - THE SERVICE PROVIDER
3.3.6.3
3.3.6.7
3.3.7
3.3.7.1
BA Other Clients
POCL
POIT
Customers
Fig. 5 - Pathway ensures that services will be managed as a discrete whole and will present a
seamless face to users, clients and customers
Through our experience in the financial and retail markets, Pathway
understands the strict service requirements of a point of service system. This
experience will ensure that the quality of service to BA/POCL is excellent.
Section 5 details the Pathway approach to service operations.
SERVICE TRANSFER
Service transfer assumes the non-renewal of the existing service agreements. In
this case, Pathway will engage in the earliest possible discussions with BA/POCL
on the one hand and with the new service provider on the other, to assess what
elements of the Pathway service could be transferred to the new supplier. This
could range from a transfer of the complete Pathway company to a partial
transfer of either fixed or human assets.
Further details on this aspect of the service will be found in Sections 5 and 8.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 12 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 3 - THE SERVICE PROVIDER
3.3.7.2
3.3.7.3
3.4
3.4.1
3.4.1.1
3.4.1.2
3.4.1.3
3.4.2
3.4.2.1
SUMMARY OF SERVICE PROVISION
Pathway understands the service needs of BA/POCL and has planned each
element of the service in a meticulous way to ensure that there are no gaps in
delivery. We are also staffing Pathway with high-quality, experienced people
who will demonstrate to BA/POCL their understanding of and commitment to
the service provision.
is in a unique position to deliver a high-quality cost-effective service to
BA/POCL in a short timescale in a low-risk manner. Pathway looks forward to
discussions with BA/POCL to demonstrate and prove our capability.
BUSINESS DEVELOPMENT AND RELATIONSHIPS
INTRODUCTION TO BUSINESS DEVELOPMENT AND RELATIONSHIPS
The success of this PFI project will be gauged by the quality of the service, the
ability of the chosen supplier to build new business streams with POCL and by
developing very good working relationships with both staff and clients.
Pathway believes it has the skills and resources to ensure this will happen.
We do not see it as our role to replace any business development role within
POCL, but rather that through partnership, we will provide additional skilled
resource to help POCL grow their business and enhance their position as the
UK’s largest retailer.
Pathway is committed to help build new business streams founded on the
strengths of POCL and the strengths of the Pathway member companies. We
shall provide a proven, flexible counter automation service, allied to the
Government’s wish to give more freedom to the Post Office. This has been
evidenced by the Green paper and the announcements in Parliament within the
past month.
POCL’S STRENGTHS
Pathway perceives POCL as currently operating from a very strong base within
the UK retail market as shown by :
(a) Broad customer base
(b) Core client base
(c) Existing skills base
(d) Network of secure counters
(e) Unique community reach
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 13 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
Si si
SECTION 3 - THE SERVICE PROVIDER
3.4.3
3.4.3.1
3.4.3.2
3.4.3.3
PATHWAY’S STRENGTHS IN BUSINESS DEVELOPMENT
We will use the commercial experience of our shareholders to share ideas with
POCL to help develop a joint business development plan where Pathway can
provide the service necessary to support the business initiatives.
(a) ICL is in the forefront of retail developments worldwide. ICL has already
had discussions with POCL in the area of kiosks as information providers.
Pathway will be happy to apply this expertise where relevant.
(b) Girobank has demonstrated its ability to establish new services with the
implementation of an electronic bill payment product for British Gas.
(c) De La Rue is in the forefront of developments in magnetic stripe and smart
card technology.
(d) Both ICL and De La Rue have recent experience of using joint ventures to
exploit new business opportunities with Camelot.
(e) Above all, each of the Pathway members has the experience of working in
consortia either together or separately. We understand the nature of them
and are confident of our ability to work together and to work also with
POCL in pursuit of building new business opportunities.
The Pathway Director - Business Development will carry responsibility for this
area of activity and further details will be found in Sections 1 and 8.
PROVEN AND FLEXIBLE AUTOMATION FACILITIES
The extensive development and growth of POCL bill payments since 1994
illustrates the potential market opportunity unlocked by the implementation of
the right technology in the right markets. This is supported by automation
developments in other major retailers, with facilities such as EPOS and in-store
computing. Automation provides POCL with the trigger to develop business
opportunities with existing and new clients by :
* Opening up the volume growth opportunity for current and new services
* Enabling growth to be cost effective
¢ Improving the ease and simplicity of transactions for the customer
¢ Enhancing the speed and quality of management information for both POCL
and its clients
* Providing on-line information based services for clients such as the
government, or the travel and entertainment sector
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 14 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 3 - THE SERVICE PROVIDER
3.4.3.4
3.4.3.5
3.4.3.6
3.4.3.7
GROWTH OF BUSINESS WITH EXISTING CLIENTS
Pathway will help POCL and its clients to establish which of these opportunities
can be enabled using the new automation facilities and will provide the retail,
marketing and IT support to bring them to market.
Pathway will work with POCL to create an integrated process to unlock the
growth potential based on the ‘Virtuous Circle’ established by POCL and
Girobank for the bill payments market. This process is carefully structured and
enables continuous improvement of both the business partnership and the
results delivered. The key elements are portrayed in Fig. 6, below.
The shareholders and suppliers of Pathway have the benefit of working with
leading retailers who demonstrate this process, and with companies who are
centres of excellence in individual parts of the process.
+ Profitabilsy/Aaivity Based
Coatings
+ DPP Category Management
+ Usage Tracking, Attibutes
+ Artibute Seoping
+ Inter Party Reviews
+ SyearPOCL Plan I
+ Market Trend Based
+ Extensive Modelling
Support
cay err ere
* Once relationship and *BILL PAYMENTS
I roles established,
L
+BANKING/FINANCIAL SERVICES * Broducp, Pricing
*INFORMATION PRODUCTS Presentation
*LICENCE APPLICATIONS I + Extensive Retail
I Comparisons
‘commence detailed
‘commercial activity plans
with commitment from
4. Operational Work Group
+ Network Teams
+ SalesTeams
= Sector Marketing Teams
+ Extensive Secondments
partnes
+ POCL with Pathway
I Support & Key Business
i
cs
+ Concern for Clients’
Customers
Fig. 6 - The Virtuous Circle
DEVELOPMENT OF NEW CLIENTS AND SERVICES
Pathway appreciates the major business opportunity POCL presents as a primary
route to market for prospective new clients and services. On this basis, we
believe that the key to success is establishing a ‘filter? for good business
opportunities to ensure that our activities are focused as efficiently as possible,
thereby delivering the maximum return on our efforts.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 15 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
“i
SECTION 3 - THE SERVICE PROVIDER
3.4.3.8
3.4.3.9
3.4.3.10
3.5
3.5.1
In order to provide this focus for our joint business development activities,
Pathway recommends the use of ‘Business Hubs’, which would form the
business centres for the management of all related business opportunities.
The use of the hub concept will help us to analyse and prioritise the extensive
business opportunities which we will face. Pathway proposes the following
business hubs :
¢ Communications.
* Personal Financial Transactions.
* Personal Applications.
¢ Travel and Entertainment.
The process for POCL and Pathway to control new business opportunities
jointly is comprised of the following activities :
* Identifying all the opportunities in each of the agreed business hubs.
* Prioritising the opportunities
* Planning the activities to exploit the opportunities.
* Resourcing the activities to exploit the opportunities
¢ Testing and implementing
FINANCIAL INFORMATION
The latest three years’ audited annual reports for British Telecom and Alliance
& Leicester are included at Annex 1. Annual reports for all the other
organisations comprising Pathway were tabled as part of the Statement of
Capability.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 16 of 16
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4 - SERVICE AND SYSTEMS ARCHITECTURE
SECTION 4 TABLE OF CONTENTS
4 SERVICE AND SYSTEMS ARCHITECTURE
4.1 INTRODUCTION ........4++
4.1.1 INTRODUCTION TO SECTION 4.1
4.1.2 THE STRUCTURE OF SECTION 4
4.1.3 OVERVIEW OF THE SYSTEM AND SERVICE ARCHITECTURE PROPOSAL
4.1.3.1 SERVICE ARCHITECTURE.....+.+sscessseersvevene
4.1.3.2 POCL STRATEGIC INFRASTRUCTURE SERVICE
4.1.3.3 BENEFIT PAYMENT SERVICE
4.1.4 BENEFITS OF PATHWAY’S PROPOSED ARCHITECTURE
WHWNNERERE
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4 - SERVICE AND SYSTEMS ARCHITECTURE
4.1
4.4.1
4.1.1.1
4.1.2
4.1.2.1
4.1.2.2
4.1.2.3
4.1.2.4
SERVICE AND SYSTEMS ARCHITECTURE
INTRODUCTION
INTRODUCTION TO SECTION 4.1
Section 4 provides details of Pathway’s proposals for the service and systems
architecture. The section follows the layout as required in the SSR. Section 4.1
describes the structure and content of Sections 4.2 to 4.6 and presents an
overview of the Pathway proposal. There is intentional overlap in some areas
between Section 4.2 and Sections 4.3 and 4.4, to avoid excessive cross
referencing and to enable each section to be independently read in conjunction
with Sections 4.1, 4.5 and 4.6.
THE STRUCTURE OF SECTION 4
Section 4.2 discusses the main determinants which have shaped the architecture
and describes the proposed architecture, its constituent service elements and
technology components. It identifies the boundaries between service elements
and summarises the end-to-end services that can be supported. It describes
‘what’ functions are included within the service and describes ‘how’ the
architecture addresses end-to-end service delivery and opportunities for a
generic approach.
Section 4.3 describes the service elements included within the POCL Strategic
Infrastructure, and the contribution each element makes to the delivery of end-
to-end services on behalf of POCL and its clients. It provides more detail of
‘what’ is provided within each service element, ‘how’ each service element is
delivered and demonstrates the ‘proof of Pathway’s ability to develop these
services. In particular, Counter Infrastructure, Transaction Management
Service, Operational Support Services and Value Added Processing are described
in Section 4.3.
Section 4.4 describes the service elements required to deliver the Benefit
Payment Service and how they interact with BA and the POCL Strategic
Infrastructure. It provides more detail on ‘what’ is provided within the Card
Management and Payment Authorisation Services, ‘how’ the overall Benefits
Payment Service is delivered and demonstrates the ‘proof’ of Pathway’s ability to
develop these services.
Section 4.5 provides answers to the specific questions (SRs 4.1 - 4.28) raised in
Chapter 4.5.2 of the SSR. Finally Section 4.6 provides a checklist of the key
objectives presented by BA/POCL within the SSR and summarises how each is
addressed within the Pathway response.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 4
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4 - SERVICE AND SYSTEMS ARCHITECTURE
4.1.3 OVERVIEW OF THE SYSTEM AND SERVICE ARCHITECTURE PROPOSAL
Pathway is a dedicated organisation created to ensure that its shareholders and
principal subcontractors have the capabilities, skills and experience required to
meet the needs of this specific procurement. These skills and capabilities
include the capacity to design, build, finance and operate the services and
systems required to meet the current stated requirements of BA/POCL.
Pathway’s architecture is designed to accommodate change in order to support
new business development and increases in business volumes in a low impact
manner.
4.1.3.1 SERVICE ARCHITECTURE
4.1.3.1.1 The design approach to the service architecture is summarised in Fig. 1 below.
7 1
Business Requirements I
Service Scmicture Options I
‘Technology Options I
I HomenFason meme I
Service Archbecure ae
Business Service
Perspective Mn Perspective
Technology
Perspective
Eneto-End Services
Benef Payments
Bill Payment & APT Migration. ~omonmmenelie I POCL Strategic Infrastructure omen od
EPOS & ECCO+ Migration Incorporate Delivered via
(Future Business Streams)
Fig. 1 - Service Architecture Approach
4.1.3.1.2 The architecture has been designed specifically to enhance the image, level and
quality of service and to ensure :
* Optimum availability of service at the counter by using built-in redundancy of
system components and replication of data within the architecture
* A cost-effective service by using commodity components, modern efficient
communications and an intuitive low training interface
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 4
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4 - SERVICE AND SYSTEMS ARCHITECTURE
4.1.3.2
4.1.3.2.1
4.1.3.2.2
4.1.3.2.3
4.1.3.2.4
4.1.3.3
4.1.3.3.1
4.1.3.3.2
* A secure and resilient service by incorporating access controls, message
authentication, audit and reconciliation mechanisms, and by the provision of
automatic synchronisation and recovery of data and services within the
architecture
* Speed of implementation and flexibility for the future by using a modular
design in the provision of the services and systems, incorporating where
appropriate open and industry standards, and by basing the solution on
existing proven products and services wherever possible
POCL STRATEGIC INFRASTRUCTURE SERVICE
Our proposal for the Strategic Infrastructure Service is based on the Riposte
system from An Post/Escher. The system components will use Microsoft
Windows NT running on Intel processors.
At a counter level the baseline proposal is a 486DX 66Mhz computer using
dedicated peripherals. Computers based on Pentium processors will provide
central transaction capture and distribution facilities. Offices will be connected
through a branch network based on Integrated Services Digital Network (ISDN).
The counter interface is the electronic desktop upon which counter staff execute
transactions. This interface will be graphical and an extension of that already
used on the ALPS project for ESNS. The infrastructure will deliver generic
applications developed from those already in use at ALPS, An Post and work
carried out for the Singapore Post Office.
The central component of the infrastructure provides a set of generic software
agents for capture and distribution of transaction information to POCL, POCL
clients and to support OSS and other Value Added Processing.
BENEFIT PAYMENT SERVICE
Our proposal for the Benefit Payment Service (BPS) consists of a dual
centralised and distributed design. The bulk processing of information from
CAPS and card management functions will be based on centralised Tandem
hardware. The payment information will be distributed through the POCL
Strategic Infrastructure to allow local positive authorisation. This allows the
continued payment of benefit in the event of network, local and central system
failures. This is a highly resilient, high-availability and flexible architecture.
The benefit card will be a high quality magnetic stripe card. The card will be
authenticated against information which is part of the payment record.
Signature verification will be part of the counter process. The payment service
can be migrated to smart cards as part of a planned evolution. The counter
infrastructure will be smart card enabled from initial roll-out.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 4
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
a ais,
SECTION 4 - SERVICE AND SYSTEMS ARCHITECTURE
4.1.4 BENEFITS OF PATHWAY’S PROPOSED ARCHITECTURE
4.1.4.1 The Pathway approach has been developed to deliver the following benefits :
* Fast, cost-effective and low-risk implementation - The architecture is built
upon existing, proven systems and services which have an excellent fit to
BA/POCL’s requirements
* Specific and exclusive focus - Pathway is an organisation which is dedicated
to meeting the needs of BA’s benefit payment programme and POCL’s
Strategic Infrastructure
* Flexibility - The solution is based on generic modules which are easy to
change and develop to meet BA’s exact requirements, and to support POCL’s
business development aspirations. The solution will also support self-service
delivery mechanisms which will become increasingly important during the life
of the contract.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 4
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
TABLE OF CONTENTS
SECTION 4.2 TABLE OF CONTENTS
4.2 SERVICE ARCHITECTURE ..
4.2.1 INTRODUCTION ........
4.2.2 PATHWAY SERVICE ARCHITECTURI
4.2.2.1 INTRODUCTION TO THE SERVICE ARCHITECTURE ..
4.2.2.2 SERVICE ARCHITECTURE OVERVIEW.
4.2.2.3 BENEFIT PAYMENTS SERVICE........
4.2.3 KEY BUSINESS AND OPERATIONAL FACTORS
4.2.3.1 BUSINESS PERSPECTIVES .....
4.2.3.2 BA ENTERPRISE MANAGEMENT
4.2.3.3 POCL ENTERPRISE MANAGEMENT .
4.2.3.4 EMPLOYEES ..
4.2.3.5 CUSTOMERS .
4.2.4 SERVICE ARCHITECTURE PERSPECTIVES
4.2.4.1 INTRODUCTION TO SERVICE ARCHITECTURE PERSPECTIVES .
4.2.4.2 SERVICE PROVISION OBJECTIVES ..
4.2.4.3 TECHNOLOGY PROVISION OBJECTIVI
4.2.5 PATHWAY’S SERVICES PROPOSAL.
4.2.5.1 INTRODUCTION...
4.2.5.2 OVERVIEW OF PATHWAY’ S SERVICE PROPOSAL.
4.2.5.3 PHYSICAL ARCHITECTURE ..
4.2.5.4 DELIVERY OF END-TO-END SERV ICES.
4.2.5.5 TRANSITION OF EXISTING SERVICES
4.2.6 PAYMENT MANAGEMENT SYSTEM
4.2.6.1 PMS OVERVIEW...
4.2.6.2 SYSTEM DESIGN FOR THE PAYMENT AUTHORISATION SERVICE:
4.2.6.3 PATHWAY PROPOSAL FOR PMS......... 18
4.2.6.4 PMS OPERATIONAL CHARACTERISTICS .
4.2.6.5 PMS SERVICE QUALITIES .....
4.2.7 CARD MANAGEMENT SYSTEM
4.2.7.1 CMS OVERVIEW ws scsesseceeeeeeees 20
4.2.7.2 PATHWAY PROPOSAL FOR CMS.
4.2.7.3 CMS OPERATIONAL CHARACTERISTICS...
4.2.7.4 CMS SERVICE QUALITIES...
4.2.7.5 CARD TECHNOLOGY OPTIONS.
4.2.8 TRANSACTION MANAGEMENT SERVICE.
4.2.8.1 TMS OVERVIEW... wee
4.2.8.2 PATHWAY PROPOSAL. FOR TM
4.2.8.3 TMS OPERATIONAL CHARACTERISTICS .
4.2.8.4 TMS SERVICE QUALITIES. ..sssscssseeeees
4.2.9 COUNTER INTERFACE SERVICE...
4,2.9,1 COUNTER INTERFACE OVERVIEW
4.2.9.2 PATHWAY PROPOSAL FOR THE COUNTER INFRASTRUCTURE .
4.2.9.3 COUNTER INTERFACE SERVICE OPERATIONAL CHARACTERISTICS
4.2.9.4 COUNTER INTERFACE SERVICE QUALITIES ...s.cssssesreesrsens 33
4.2.10 OPERATIONAL SUPPORT SERVICES 34
4.2.10.1 OSS OVERVIEW .... cece 34
4.2,10.2 PATHWAY'S PROPOSAL FOR OSS
4.2.10.3 OSS OPERATIONAL CHARACTERISTICS
4,2.10.4 OSS SERVICE QUALITIES...
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
4.2.11 THE NETWORK INFRASTRUCTURE ..
4.2.41.4 PATHWAY’S PROPOSAL FOR THE NETWO!
4,2.14.2 POST OFFICE LOCAL AREA NETWORK (LAN)
4,2.11.3 BRANCH WIDE AREA NETWORK (WAN) ......
4,2.11.4 CORRESPONDENCE SERVER BACKBONE NETWORK.
4.2.12 SERVICE BOUNDARIES AND INTERFACES..
4,2.12.1 INTRODUCTION......
4,2,12.2 SERVICE INTERFACES
4.2.13 PATHWAY SUPPORT SERVICES
4.2.13. INTRODUCTION
4,2.13.2 HELP DESKS
4.2.14 SUMMARY .....
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4,2 - SERVICE ARCHITECTURE
4.2
4.2.4
4211
4.2.1.2
4.2.1.3
4.2.14
4.2.2
4.2.2.1
4.2.2.1.1
4.2.2,1.2
SERVICE ARCHITECTURE
INTRODUCTION
This section describes Pathway’s proposal for the service architecture and in
particular explains how Pathway will meet the functional requirements of
Benefit Agency and POCL as described in Chapter 4 of the SSR.
Section 4.2.2 contains a description of the architectural approach adopted by
Pathway. This approach conforms to the service architecture contained in the
SSR. The principal business and operational characteristics required by BA and
POCL for each service or system element are assessed in Section 4.2.3. Section
4.2.4 describes the service provision and technology provision objectives of the
architecture.
This is followed in Section 4.2.5 by an overview of Pathway’s proposals for the
primary system and service elements together with a summary of how the end-
to-end service and transition requirements will be met. The functionality that
will be provided by each service element of Pathway’s proposal is explained in
Section 4.2.6 to Section 4.2.11.
Section 4.2.12 describes the nature of the primary service boundaries and
interfaces. Section 4.2.13 contains a summary of the main support processes
that Pathway will use to underpin service management and control. Section
4.2.14 provides a summary of the benefits and uniques advantages of the
Pathway service architecture.
PATHWAY SERVICE ARCHITECTURE
INTRODUCTION TO THE SERVICE ARCHITECTURE
Pathway has based its development of the service and systems architecture on a
sound understanding of the business requirements and operational
characteristics as set out in the SSR. Pathway has also taken due account of the
likely service developments that will be required in the future.
Our proposal for the service architecture is based on the unique insight and
understanding that members of the Pathway consortium have of the needs of BA
and POCL. Both ICL and Girobank have been trusted business partners of BA
and POCL for many years. An Post and Escher bring vision and confidence
born of a successful post office counter automation strategy. De La Rue has a
unique understanding of card technologies and future developments.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4,2.2.1.3 A fundamental criterion for a service and systems architecture is its ability to
accommodate change whether this occurs within the business, social or
technological domains of BA or POCL. Both BA and POCL already have many
of the key elements of the business architecture in place. The strategic goals of
both organisations and the service architecture for this procurement are
expressed in the SSR. Pathway has combined these key elements and the need
for accommodating change with its own skills and expertise to develop a service
and systems strategy which will :
* Meet the functional requirements of BA for benefit payments
* Meer the strategic requirements of POCL for counter automation
¢ Allow for business growth in POCL
* Support POCL’s new business development objectives
* Be aligned to existing BA and POCL systems
¢ Give potential for rapid change
* Be cost effective to install and operate
4.2.2.2 SERVICE ARCHITECTURE OVERVIEW
4.2,2.2.1 Pathway’s proposal for the service architecture conforms to the service
architecture described in Chapter 4.1 of the SSR and reproduced in Fig. 1 below.
This identifies a number of system services (such as card management) and
functional system components (such as the counter interface).
“Value Added
Pecan
poct
ae
(eon 0162)
\Cusemes
Fig. 1 - The SSR Service Architecture
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.2.2.2 Pathway endorses this general architectural framework as the strategic approach
for delivery of IT services within POCL, including the payment of benefits on
behalf of BA. Pathway’s approach is to provide a set of service components
with well-defined interfaces which when used together will provide end-to-end
service delivery between POCL clients and their customers. This approach
supports the cost-effective delivery of the initial service requirements, and also
provides a generic framework for the introduction of new client services within
a single, consistent overall architecture.
4.2.2.2.3 The initial end-to-end services that Pathway will support through this
architecture are :
* Benefits Payments
* Bill Payments including APT migration
* EPOS including ECCO+ migration
* OSS functions
4.2.2.3 BENEFIT PAYMENTS SERVICE
4.2.2.3.1 The Benefit Payment Service (BPS) is separated into the Card Management
Service (CMS) and the Payment Authorisation Service (PAS). CMS includes the
areas of card production, card personalisation, card collection and management
of a cardholder database and provision of a card help desk. PMS includes
payment management, payment encashment and help desk. An overview of
CMS and PMS is shown in Fig. 2.
Client Facing Environment
—_ _ a _
Card 4 4h I Payment
Production I Management
Payment
‘Authorisation
I Card Payment I
I Collection I I Collection
Customer Facing Environment :
Fig, 2 - The Benefit Payment Service
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2,.2.3.2
4.2,2.3.3
4.2.,2.3.4
4.2.2.3.5
4.2.2.3.6
4.2.3
4.2.3.1
4.2.3.1.1
The Transaction Management Service (TMS) functions control the transfer of
card and payment information between the customer-facing and client-facing
environments in a secure and timely manner.
The key tasks of the Card Management Service (CMS) includes the ongoing
management of a cardholder database and all of the bulk processing tasks
associated with card production, personalisation and distribution. These
activities are well understood by Pathway and will be delivered on a centralised
system using established procedures and standards.
Pathway’s design for the Benefit Payment Service separates the bulk processing
of payment transfer and validation from the processes required to ensure timely
and reliable payment collection at the post office counter.
Pathway will implement a centralised system for bulk processing tasks, this
component of the service and systems architecture is called the Payment
Management System (PMS).
PC-based technology and peripherals will be delivered as part of the Pathway
proposal for the POCL Strategic Infrastructure. Payment will take place at the
post office counter and Pathway will distribute all the data required for benefit
encashment to the point of payment based on the very strong relationship
between the benefit customer and their nominated post office (the customer/post
office relationship is not absolute and the design also supports instances where
the relationship is non-existent such as foreign encashments).
KEY BUSINESS AND OPERATIONAL FACTORS
BUSINESS PERSPECTIVES
By developing the service architecture in the light of the rich body of experience
available, Pathway has set stringent selection criteria for its constituent service
and system elements. These criteria will ensure that the architecture delivers
reliable, cost-effective services that conform to the corporate requirements of BA
and POCL and are acceptable and useable at the individual level by customers
and employees.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ei
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.3.1.2
4.2.3.2
4.2.3.2.1
4.2.3,.2.2
4.2.3.2.3
4.2.3.2.4
4.2.3.3
4.2.3.3.1
4,.2.3.3.2
eee
I BA Enterprise
I Management
~ ~~
{ )
POCL Enterprise
Management
( Service and
I Systems
(Architecture
—
Employees
Fig. 3 - Business Perspectives
Each of the groups of service users shown in Fig. 3 will have a different view, or
perspective, of the services or systems within the architecture which must reflect
the business trends and personal expectations of the people in these roles. A
summary of the key perspectives which Pathway has considered for each of
these groups is presented in Section 4.2.3.2 to Section 4.2.3.5.
BA ENTERPRISE MANAGEMENT
BA’s strategic goal is to provide an efficient and reliable one-stop service for its
customers. The overall Benefit Payment Service (BPS) must deliver the right
money to the right person at the right time.
BA expects significant cost reductions through a reduction in the administrative
costs of running the current benefit system and a major reduction in fraud.
There is increasing pressure to exercise stricter controls over the DSS budget and
accordingly, full accountability for all the benefit payments awarded and
subsequently encashed is a primary requirement.
BA wishes to take advantage of the benefits that service-quality and usage-based
charging mechanisms can bring within an overall PFI procurement.
POCL ENTERPRISE MANAGEMENT
POCL wishes to maintain and develop the range of business services currently
provided for their clients.
POCL wishes to become the leading provider of benefit distribution, postal
service, banking and bill payment facilities and to use counter automation
technologies to achieve these goals.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
oi
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.3.3.3
4.2.3.3.4
4.2.3.3.5
4.2.3.3.6
4.2,3.3.7
Continuous improvement in customer service remains a high priority, as does
the most effective utilisation of the nationwide network of Post Office outlets.
POCL Organisation
The benefit payment system will operate across the Post Office network of
approximately 19,700 locations, supporting approximately 40,000 counter
positions.
The post office network has a diversity of locations, counter positions, social
importance and physical characteristics. Some post offices provide essential
services to small rural communities yet conduct comparatively low business
volumes. Others in major city centres and urban areas conduct much larger
volumes of business in terms of number and value. An overview of the post
office counter distribution is presented in Fig 4
Number
of post offices
10000
8000 ]
6000
fo
I
2000
0
3-5 6-12 >12
RB
is)
Number of counters per post office
Fig. 4- Distribution of post offices
Pathway research indicates the distribution of post offices is skewed towards a
large number of agency offices (range 1 - 3 counters) undertaking the bulk of
POCL business. The relatively few large post offices, those with 6 and more
counters, carry out about a third of the business transactions and are most
efficient in terms of counter time.
The chart includes 5,000 of the smallest rural sub-post offices which together
are responsible for only 1% of all post office business (This information has
been extracted from ‘Rural Benefits’ a report, dated Feb. 1995 by the National
Association of Citizens Advice Bureaux). This report is available upon request.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.3.3.8
4.2.3.3.9
4.2.3.4
4.2.3.4.1
4.2.3.4.2
4.2.3.4.3
4.2.3.4.4
4.2.3.5
4,2.3.5.1
4.2,3.5.2
4.2.3.5.3
Pathway has assessed the cost/benefit implications of these estimates in
determining a strategy for counter infrastructure. Whilst supporting the
principle of universality, Pathway’s systems architecture will allow a flexible
approach to be taken in supporting the benefit payment process at the counter.
Different levels of counter infrastructure can be accommodated in order to
support the POCL critical success factor of affordability. The F85 device from
De La Rue Fortronic deserves further investigation as a viable counter option.
Details of the De La Rue Fortronic F85 device are given in Annex 4 - Baseline
Proposal Summary and Options.
EMPLOYEES
Post office counter staff expect the new systems and processes to improve their
ability to serve the customer, and to reduce administration tasks.
The design of new systems and processes must not be adversely intrusive and
should inspire confidence and acceptance. Pathway will ensure that the system
processes do not create barriers between customers and counter staff. The
system will inspire staff confidence and pride and enhance the long established
post office reputation for friendly efficient service.
As part of its continuous information acquisition process, Pathway has
participated in events organised by the National Federation of Sub-postmasters
(NFSP) and has received useful feedback on their needs and concerns. One area
of concern relates to personal and premises security. Pathway would like
further discussion with POCL and NFSP to assess how best security monitoring
could be integrated into the infrastructure.
BA staff who interact with the benefit payment system (through help desks,
emergency payment procedures, and so on) must encounter effective and
efficient procedures and systems that aid their overall responsibilities,
effectiveness and ability to deliver customer service.
CUSTOMERS
Customers of BA and POCL represent a broad social spectrum with a wide
range of requirements and expectations.
BA customers expect the introduction of the BA card to be personally and
socially acceptable and they expect that the obligations it places on them to be
just and reasonable. The changes in the payment process must be simple,
efficient and seen to be of benefit.
Other POCL customers will expect overall service quality to improve. Counter
time and queue time must not be jeopardised, and there must be demonstrable
reasons for continuing to use the Post Office network.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 7 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4,2 - SERVICE ARCHITECTURE
4.2.3.5.4
4.2.3.5.5
4.2.3.5.6
4.2.3.5.7
4.24
4.2.4.1
4.24.11
4.2.4.2
4.2.4.2.1
Social Factors
Pathway understands that there is a strong association between the BA customer
and a nominated post office for benefit collection. The SSR estimates this at
between 90% and 95% of all encashments.
The association between customer and nominated office is part of the social
environment within which benefit payments take place and the strength of this
association provides one of the key foundations supporting this procurement
and Pathway’s proposal. The Benefit Payment Service proposed by Pathway is
optimised to exploit this relationship whilst providing full support for agents
and foreign encashments that in no way inhibits service quality.
Pathway is particularly mindful of the broad social spectrum that will be affected
by the introduction of the new card-based Benefit Payment Service. In order to
ensure that we have the fullest understanding of the needs of all groups in
society Pathway has conducted market research and has met with many groups
in the voluntary sector.
Among the groups surveyed and consulted were Age Concern, MENCAP, and
the Carers National Association. The findings from these studies are contained
in Annex 8 - Research Programmes and provide a valuable insight into the
factors that must be considered in the final service design and roll-out.
SERVICE ARCHITECTURE PERSPECTIVES
INTRODUCTION TO SERVICE ARCHITECTURE PERSPECTIVES
The architecture developed by Pathway may be viewed from two perspectives :
service provision and technology provision. Both views have common unifying
objectives but the architectural choices provided by each perspective are driven
by different considerations.
SERVICE PROVISION OBJECTIVES
In terms of service provision, the key objectives of the architecture are to define
clear and efficient service boundaries. Each service boundary must :
* Support effective delivery of end-to-end service through the constituent
components
* Provide effective separation between Service Provider and service user
responsibilities
« Support an appropriate range of options for service and pricing levels
* Provide a clear boundary for reconciliation and settlement between the
parties
* Facilitate change in existing or new service components
¢ Support contract exit or transfer for the various constituent services
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 8 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4,2.4.2.2
4,2.4.2.3
4,.2.4.2.4
Service Boundaries and End-to-end Service Delivery
The end-to-end services are the Information Systems and operational procedures
which support the overall business processes required to accept a request for
service from a customer (for example a benefit customer) and to deliver the
information to the client (in this case return of encashment details to BA).
The delivery of such end-to-end services requires that each service organisation
operates to an agreed service boundary. This service boundary will define the
means by which financial reconciliation, service monitoring and service charging
are provided between the service element providers. Service boundary
definitions and SLAs will apply within Pathway and between Pathway and the
contracting authorities. Typically these definitions will consist of agreements on
the service metrics shown in Fig. 5.
I Service I
I Element I
I Service Level Agreements
(Assurance
Service Provider
Fig. 5 - Service Boundaries
Service Boundary elements
The primary elements that will define a service boundary are :
(a) Capacity - A definition of the information flows that the service boundary
must support. This will include volumetrics, time constraints, and physical
characteristics of the information flow including the type of IT systems and
protocols used.
(b) Service Level Agreements - A definition of the metrics and methods of
assessing whether the service boundary is meeting the requirements of the
service user. In addition the responsibilities of the Service Provider and the
Service Recipient will be defined in the context of the end-to-end service.
(c) Assurance - The definition of the processes that will ensure information
flows across the service boundary are accurate and reconcilable.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 9 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
yy
SECTION 4.2 - SERVICE ARCHITECTURE
(d) Contract Relationship - A description of the means by which either party
can terminate the agreement or be substituted. Depending on the nature of
the Service Boundary this may form part of the legal definition of the
service responsibilities.
(e) Charging - This will include details of the metrics and methods to be used
for charging for the service. This will also include the circumstances under
which any penalty clauses may be invoked and how these process should be
managed.
4.2.4.3 TECHNOLOGY PROVISION OBJECTIVES
4.2.4.3.1 The key objectives are to support efficient technology integration over the life of
the service, and to deliver the required system characteristics in a cost-effective
way. Pathway has selected technology which has the following objectives :
* To exploit proven and cost-effective industry standard components
* To facilitate the integration of existing system components
* To facilitate the fast and efficient introduction of new technology and
applications
* To deliver end-to-end systems performance in the most cost-effective manner
* To deliver end-to-end systems availability in the most cost-effective manner
* To provide the requisite levels of system security
* To provide high levels of usability at the boundary between the system and its
users
* To eliminate any system management responsibilities from the counter staff
or the Postmaster
Pathway System Architecture Design
4.2.4.3.2 The system architecture shown in Fig. 6 illustrates Pathway’s approach to system
design and construction. The architecture provides a rich, flexible and resilient
counter infrastructure linked through a Transaction Management Service to a
wide range of enterprise-level services. These include central POIT services and
the specific Card and Payment Management Services operated by the Service
Provider to support BA benefit payments.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 10 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ie
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.4.3.3
4.2.4.3.4
4.2.4.3.5
4.2.4.3.6
BA & Other Clients
---- { Client Interfaces I --
I Bill
CMS I PMS I jPayment
i & VAP
:
: j
~ Real Time & Batch Interfaces
Transaction Management
€
~ = =~ Transaction Support Interface
Counter & Back Office Applications
~~-~~~§- User Interface -§-~-~~
Customers
Fig. 6 - Pathway System Architecture
Each service layer within the architecture provides a set of generic facilities to
support its role within the end-to-end service-delivery model. Specifically this
means that the interfaces at a technology level are defined as generic and that
the components of the service layer are driven by parameters where possible.
The interface supports transactional and batch data flows to and from BA,
POCL and other clients. The transaction support interface provides a generic
set of facilities for the development and operation of counter applications. The
introduction of new applications will in general only require a non-
programming definition of the new application using the parameters.
An example of the high level of parameterisation for the introduction of new bill
payments at the counter is discussed in Section 4.3.3.4.
The same parameterised architectural model is followed for all service functions
including all Value Added Processing, internal OSS processing or other Service
Provider functions.
During transition to the full strategic infrastructure and counter systems,
Pathway’s roll-out strategy anticipates interfacing TMS and the counter interface
to existing POIT services including Host Polling. This is discussed further in
Section 7 - Roll-out and Implementation and in Section 4.5 SR4.3 and SR 4.4.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 11 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ie
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.5 PATHWAY’S SERVICES PROPOSAL
4.2.5.1 INTRODUCTION
4.2.5.1.1 Section 4.2.5 provides a summary of Pathway’s proposal for each of the service
elements contained in the service architecture. We describe the physical systems
architecture and we map the key system processes onto the architecture.
4.2.5,1.2 More detailed information of how Pathway’s services proposal will be provided
is contained in Section 4.3 - POCL Strategic Infrastructure Service and Section
4.4 - Benefit Payment Service.
4.2.5.2 OVERVIEW OF PATHWAY’S SERVICE PROPOSAL
4.25.21 Pathway has selected the following organisations from within the consortium to
take responsibility for delivery of the key service components as shown in the
table below.
5.2.5,2.2 This selection has been based on their proven expertise and track record,
together with the general philosophy that service ownership should be placed
with the organisation best able to manage the associated risks.
This Service Will be based on these elements : Delivered by this
Component : part of Pathway:
Payment New development based on existing Girobank
Management Girobank systems
Service
Card GENcard - the card management system I Alliance &
Management from Applied Communications Inc Leicester
Service Card production, personalisation and
distribution De La Rue
Transaction The Riposte distributed messaging ICL and
Management system from An Post/Escher and Girobank
Service supporting services
Counter PC infrastructure and counter ICL
Interface applications from An Post/Escher
Operational New developments based on existing Girobank
Support Services I applications from An Post and
Girobank
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 12 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.5.3
4.2.5.3.1
4.2.5.3.2
4.2.5.3.3
PHYSICAL ARCHITECTURE
The physical architecture can be considered across three primary layers together
with the network infrastructure which links them. These layers are shown in
Fig. 7 and comprise :
* The Central layer - which provides the primary links with POCL clients
* The TMS layer - which will utilise the Riposte distributed messaging system
* The Post Office layer - which supports the POCL counter infrastructure
Central Services
Layer
Saven TMS Layer
9 (federated for resilience)
on a we
(arch SDN Network
(
oN LA
eee eco we =
Fig, 7 - Pathway physical architecture
Central Layer
The central systems running at this layer will be the CMS, PMS and the central
functions of OSS. These services will be operated by Alliance & Leicester and
its subsidiary Girobank. These are centralised systems and they will be based on
Tandem Himalaya hardware. These central systems will be located in secure
data centres and will utilise the standard resilience features of Tandem including
fail-safe operation and data duplication, Multiple data centres will be used to
ensure service availability in the event of physical disaster.
TMS Layer
The TMS layer is composed of a number of Windows-NT servers running the
An Post/Escher Riposte distributed messaging system. These are known as
correspondence servers and each server will have responsibility for a group of
post offices.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 13 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.5,3.4
4.2.5.3.5
4.2.5.3.6
4.2.5,3.7
4.2.5.3.8
4.2.5.4
4.25.41
4.2.5.4.2
4.2.5.4.3
Pathway’s design for TMS is based on grouping together correspondence servers
to form a resilient hierarchy with each group located in separate secure data
centres. The Riposte system replicates all transactions that occur within an
individual post office across the WAN to its primary correspondence server and
this in turn replicates the transactions to other correspondence servers in the
same and separate groups.
This approach ensures that all transactions are completely secure and are always
available for recovery should a failure occur in any server or post office.
Additional servers will provide the facilities to extract information from TMS.
These will run generic software modules, known as TMS software agents, which
are dedicated to particular POCL clients. These software agents will cater for
particular transaction transfer service levels and data formatting requirements.
Post Office Layer
The Post Office layer consists of the PC-based counter infrastructure together
with the counter peripherals required for the initial services being deployed.
These will include magnetic stripe and smart card readers, OCR and bar code
readers, a desktop receipt printer and a compact monitor and compact
keyboard. A printer suitable for ‘back-office printing’ will be supplied for each
post office.
This infrastructure supports the counter applications, the local OSS functions
and also uses the local layer of Riposte to manage the transaction replication
within a post office and across the WAN to the TMS layer.
DELIVERY OF END-TO-END SERVICES
All the components of the service layers combine to provide reliable and
efficient delivery of end-to-end service. The initial set of services is described
below. The architecture is open and extensible to enable additional services to
be added as required.
Benefit Payment Service
The Benefit Payment Service is delivered efficiently and in a highly controlled
way through the service layers. Authorised payments from CAPS are pre-
processed through PMS (which uses CMS verification data). The authorised
payments are distributed to the customers’ nominated post offices using TMS.
The payment process is supported at the counter where, for the majority of
encashments, payment will take place using locally held authorised payment
details. Foreign payments are supported by using TMS to retrieve details from
the customer’s nominated post office. Pathway’s choice of Riposte for TMS will
enable foreign payments to take place in a seamless and timely fashion with no
explicit action required by either the customer or post office counter staff.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 14 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.5.4.4
4.2.5.4.5
4.2.5.4.6
4.2.5.4.7
4.2.5.4.8
4.2.5.4.9
4.2.5.4.10
The counter interface application is based on the existing benefit payment
application in use in An Post and operates within the set of generic transaction
types provided by Riposte. The application manages the payment process and
details of encashments and exceptions are fed back to CAPS via TMS.
Riposte provides a high-speed distributed messaging environment which is
already proven within An Post and forms the basis of the ESNS system. A
detailed description of the Riposte system is provided in Sections 4.3.4.2 to
4.3.4.9,
The service supports both the customer in providing an efficient and reliable
benefit payment process and BA in ensuring timely access to payment details
(for enquiry and stop placement) and encashment information.
Bill Payments
The Pathway bill payment application is based on an existing Bill Payment
application in use in An Post and already satisfies the needs of the majority of
bill types and payment methods. This application operates within the generic
set of transaction types provided by Riposte.
The flexible nature of the bill payment module and the ability to introduce new
bill payment streams for other utilities or companies is discussed in Section
4.3.3.4.
The OCR line of the Bill is read (or keyed) at the counter, the payment (or part
payment) is typed in and the transaction is routed to the correspondence server.
ATMS software agent will aggregate the bill payment details for each client and
will typically route all the payments for the day to the client as part of an
overnight Value Added Process. The transaction details and moneys received at
the counter will be recorded locally for inclusion in the end-of-day balancing
and Cash Account.
EPOS
Pathway will re-use and enhance an existing post office EPOS application for
use by POCL. This will enable the counter staff to record all transactions
(including sales of products) and accumulate cash received against product
codes. This information is fed into the end-of-day processing for Cash Account
production and office reporting. The information captured will be available to
other applications including stock control. Pathway envisages that a number of
the transaction types initially captured via EPOS will be developed further to
provide more advanced transaction capture facilities (e.g. use of bar-coded client
forms).
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 15 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARC!
ECTURE
4.2.5.5
4.2.5.5.1
4.2.5.5.2
4.2,5.5.3
4.2.5.5.4
4.2,5.5.5
4.2.5.5.6
TRANSITION OF EXISTING SERVICES
Automated Payments Terminal (APT)
The APT supports bill payments and pre-payments. Bill payments will be
supported in the new counter application described in Section 4.2.5.4.7 to
4.2.5.4.9. The pre-payment aspect comprises two activities.
(i) Utility stamps -This will be covered by the new EPOS application described in
Section 4.2.5.4.10.
(ii)Smart card and Schlumberger key re-charging
Pathway wishes to discuss the possible re-use of the existing re-charging
equipment. Options include the retention of some or all of the current counter
equipment or the inclusion of their functionality within the new counter
equipment.
The British Gas Quantum system invokes its own ISDN link to British Gas.
Pathway will investigate with British Gas how this link is best incorporated into
the new counter infrastructure.
ECCO+
ECCO+ is an EPOS system, and equivalent functionality is being implemented
in the new EPOS application.
CRISP
Pathway recognises that Post Shop has already made a significant investment in
the RIVA point of sale system and that in general there are a number of key
differentiators between this retail operation and the counter automation
requirement. Pathway understands that a new range of RIVA EPOS systems is
likely to be deployed in Post Shops in parallel with this procurement. In any
event discussions with Post Shop will be needed to understand the range of
current operations and the requirements for a consistent set of stock codes
within POCL.
Pathway has entered into preliminary discussions with RIVA Systems Limited to
assess the opportunities for integration of the Post Shop EPOS application with
the wider counter interface environment. It is anticipated that this could occur
at two levels :
(a) The first level would be aimed at rationalising the use of LANs and network
access, to avoid equipment duplication and support consistent network
access from the post offices.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 16 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.5.5.7
4.2.5,5.8
4.2.6
4.2.6.1
4.2.6.1.1
4,2.6.1.2
4.2.6.2
4.2.6.2.1
(b) The second level would be aimed at application-level integration between
the two systems, in the areas of stock management and cash
balancing/reconciliation.
CAPTURE
Capture is a back-office cash accounting package which is in widespread use and
produces a number of reports required by POCL. The functionality of Capture
will be replaced by the new OSS system.
ESNS
Pathway’s roll-out strategy recommends extending the use of an enhanced ESNS
to all post offices as the first step towards the automation of benefit payments.
This will enable the advantages and benefits of ESNS already achieved to be
rapidly extended across all post offices. ESNS will remain in use until the final
cut-over from paper-based to card-based payments has occurred.
PAYMENT MANAGEMENT SYSTEM
PMS OVERVIEW
This central system controls the input of the payments and related information
from CAPS through to the distribution of payment authorisation information to
the post office counter systems. PMS also receives feedback from the counter
systems on changes to payment status. It notifies CAPS of all payment
encashments and expiries and satisfies related information needs.
PMS merges the payment information (from CAPS) with the card information
(from CMS) required for authentication and verification. It records the status of
issued cards, controls exceptional card usage (including the use of temporary
tokens), and ensures that changes in personal details are properly managed.
PMS maintains a payments database which is used in a number of central
functions, such as overall BA/POCL payment reconciliation, audits, MIS queries
and reports.
SYSTEM DESIGN FOR THE PAYMENT AUTHORISATION SERVICE
The operational characteristics of payment authorisation separate into two
distinct classes. The requirement for PMS to bulk process approximately 20M
payment records per week, together with any associated verification data from
CMS clearly requires a central data processing capacity. A central processing
model is required in order that a single interface with CAPS can be developed
and managed. This will facilitate any data archive, analysis and audit tasks that
will be required.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 17 of 46
OJEC Notice 94/S 165-S8937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.6,2.2
4.2.6.3.2
4.2.6.2.4
4,2.6.2.5
4.2.6.3
4.2.6.3.1
4.2.6.3.2
The payment process at the counter, however, is one that has a highly
predictable association between the customer transaction and the point of
encashment with more than 90% of payments occurring at the nominated post
office. An Post’s experience also supports POCL’s view that payments for a
number of benefit types are made within a few hours of them becoming due,
resulting in a demand for speedy and reliable payment authorisation.
Pathway has adopted the localised data option for benefit encashment. Once
the bulk receipt and validation of benefit payments from CAPS has occurred,
files of payments for each post office will be created, secured and distributed.
The benefit encashment process will then take place locally using the PC-based
counter infrastructure. Foreign payments will be supported by using the high-
speed data retrieval mechanism of TMS to access payment data outside of the
local data store.
This approach reduces the complexity and cost of the central systems to those
tasks involved in managing the bulk processing and transfer of data to and from
CAPS and the counter environment (via TMS). This decentralised approach
provides very high levels of resilience and concurrent processing at lower cost.
The system is also readily scaleable allowing additional counter positions to be
added in post offices without any impact on central systems. Additional post
offices may be added to the network with relative ease.
In addition the network costs associated with bulk data transfer to 20,000 post
offices are significantly lower than handling 20,000,000 on-line encashments
per week. Counter transaction time will be reduced and predictable since there
will be no external factors such as the surges in CPU usage normally associated
with morning processing in central systems affecting the response times of any
single counter position.
PATHWAY PROPOSAL FOR PMS
PMS will be developed and operated by Alliance & Leicester. This system will
be developed from the existing girocheque system which is a proven set of
applications responsible for the management of approximately 100 million
girocheques per annum. Girobank’s development capability is illustrated in the
case study on the BA/Girocheque project. This project is described in Annex.
6.7 - BA Project.
That component of the BPS associated with authorisation and encashment at the
post office counter will be based on the An Post/Escher Riposte system.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 18 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ie
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.6.4 PMS OPERATIONAL CHARACTERISTICS
4.2.6.4.1 The operational characteristics of PMS used as input to the design process are
listed in the following table :
This PMS process : Has these operational characteristics :
Payment management - covers the I Processes between 1.6M and 6M records
receipt of payments from CAPS, per day and caters for low-volume, high-
their validation and acceptance or I priority emergency payments
rejection
Payment verification - covers the I Uses card details held within CMS
linking of payment records with
additional verification data
Payment distribution - makes the I Enables each post office to access
payment information available at I payment records
the point of encashment
Payment encashment - covers the I Enables each post office to encash
processes of identification (of benefits in an efficient and low-risk
benefit), authentication (of card) I manner and will cope with the
and verification (of customer) encashment volumes expected in large
post offices a:
Payment expiry - ensures that Enables each post office to automatically
details of expired benefit return expired payments to BA via TMS
payments are returned to BA
4.2.6.5 PMS SERVICE QUALITIES
4.2.6.5.1 The service qualities which were analysed and used as part of the criteria for
PMS are described in the following sections.
Availability
4.2.6.5.2 Pathway’s design for PMS will ensure that benefit payments can be made in all
circumstances. The design will be flexible and robust such that benefit payments
are not dependant on any single service component. A modular and hierarchic
architecture will be used to ensure that a service-component failure within the
layers of the architecture can be accommodated without the overall service being
jeopardised.
4.2.6.5.3 Pathway’s design removes single points of failure through the use of a proven
distributed architecture for the counter infrastructure. The central PMS will be
developed from Girobank’s existing girocheque system which meets and exceeds
all service levels required by BA.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 19 of 46
OJEC Notice 94/S 165-58937/EN
Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.6.5.4
4.2.6.5.5
4.2.6.5.6
4.2.6.5.7
4.2.6.5.8
4.2.6.5.9
Performance
Speed and efficiency are essential aspects of all post office counter transactions.
The introduction of a new BPS must not jeopardise POCL’s standards for
customer service, and must result in a more efficient process for the overall
management of benefit payments and all other transaction types.
Pathway’s architecture supports performance improvement and will ensure that
overall customer service capability of an individual counter and at each post
office is enhanced.
By using Girobank’s unique operational expertise as a business partner of BA,
and by adopting an overall systems architecture which maximises concurrent
processing over the distributed counter infrastructure a high level of end-to-end
performance will be achieved.
Security
The security attributes of PMS will conform to an overall security strategy for all
service components within the Procurement Service Boundary. This is described
in Annex 5 - Pathway Security Policy.
Specific security measures include :
(a) Confidentiality - Pathway will ensure that information is only disclosed to
authorised users by using secure access techniques including user roles and
strict password controls. This will apply to all users, including post office
counter staff, help desk staff and any external users.
(b) Integrity - Pathway will ensure that the integrity of information contained
within PMS, TMS and distributed to the post offices is maintained by
ensuring that modifications can only take place by users or systems with the
right to do so, and only in authorised ways. CRCs and digital signatures
will be applied to provide the required level of protection. This is discussed
further in Section 4.3.4.8.
(c) Accountability - Pathway will ensure that all activities having a material
effect on the service will be recorded in audit logs. These will be retained
and archived for subsequent analysis if required.
By using secure data techniques and access controls, Pathway will ensure that
the operation of PMS will conform to the high operational standards expected
by BA and POCL.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 20 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.7
4.2.7.1
4.2.7.1.1
4.2.7.1.2
4.2.7.1.3
4.2.7.2
4.2.7.2.1
4.2.7.2.2
4,2.7.2.3
4.2.7.2.4
CARD MANAGEMENT SYSTEM
CMS OVERVIEW
The Card Management Service will manage the production, issue and
distribution of cards and pick up notices (PUNs) to a card population of
approximately 25M people. It will maintain sufficient and timely data on cards
and tokens to ensure that authorised cards and tokens are issued only to
approved customers and their agents, and that they are only available for use for
customers to receive authorised benefits.
CMS will provide efficient processes for handling card enquiries from BA and
reports of lost, stolen and damaged cards from customers. The service will also
provide secure interfaces to the Payment Management Service (for the supply of
card verification details) and with the Post Office network (for the distribution
and issue of cards).
Pathway’s proposal for the initial release of the BA card is to use magnetic cards
with a paper signature panel which is indent printed. Pathway believes that
during the life of this procurement there will be a migration to smart cards.
Pathway’s card migration strategy and an assessment of the merits of magnetic
stripe and smart cards is summarised in Section 4.2.7.5. Further details are
provided in Annex 9 - Technology Trends.
PATHWAY PROPOSAL FOR CMS
Pathway proposes to use the ACI’s Card Management System (GENcard) to
provide a cardholder database and manage the process of card production,
dispatch and activation.
Pathway has assigned responsibility for the operation of this service to Alliance
& Leicester, because of its proven capability and adherence to quality standards.
Alliance & Leicester will provide all required services including the management
of the cardholder database, management of the information flows with BA and
with the card producer, technical support and operation of the CMS help desk.
Pathway has selected De La Rue to manage the production, personalisation and
distribution of the BA Card and the pick up notice (PUN). De La Rue is the
UK’s leading provider of magnetic cards with greater than 60% of the UK
market. De La Rue has the capacity and quality processes in place to meet the
requirements for providing approximately 25 million BA cards and their
subsequent renewal. De La Rue’s capability is illustrated in the case studies for
PostBank and De La Rue Card Technology which are described in Annex 6.6
and 6.16.
De la Rue is heavily involved in the development of smart card standards and
technology and has an expandable production capacity to meet BA and other
POCL clients’ requirements as they emerge.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 21 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.7.3 CMS OPERATIONAL CHARACTERISTICS
4.2.7.3.1 The CMS operational characteristics which were used as input to the system
design for PMS are listed in the table below :
This CMS process : Has these operational characteristics :
Card preparation - coversthe I The receipt of approximately 50k card
receipt of card details from details per day average and up to 100k cards
CAPS, their validation and per day peak
acceptance or rejection
Card 8& PUN production - The production and personalisation of
covers the transmission of card I approximately 50K cards and PUNs per day
details for physical card and
PUN production
Card & PUN distribution - The production and distribution of
covers the batching and secure I approximately 50K PUNs together with
delivery of cards (to post their unique card code to BA customers.
offices) and pick up notices (to I The co-ordinated distribution of card
the customer) batches to post offices
Card collection - covers the To ensure that a secure process is used so
counter processes of card issue I that cards delivered to post offices cannot be
and card activation used before issue to the customer
4,2.7.3.2 Operational volumes will be much higher during initial card introduction. Lost,
stolen and damaged rates of renewal are also likely to be higher during this
period of public acceptance. Pathway will plan to have sufficient stock in place
to support these high-volume phases.
4.2.7.4 CMS SERVICE QUALITIES
4.2.7.4.1 In the following sections we examine the service qualities that were considered
in the initial design.
Security
4.2.7.4.2 By basing CMS on ACT’s industry-leading card management system, a secure,
reliable and auditable service is assured. Secure access techniques for all user
access will be used. In addition all CMS data will be subject to the Data
Protection Act. Further details of Pathway’s security strategy are contained in
Annex 5. The complete production and personalisation process for cards is
given in Section 4.4.4.4.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 22 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.7.4.3
4.2.7.4.4
4.2.7.4.5
4.2.74.6
4.2.7.4.7
4.2.7.4.8
4.2.7.5
42.7.5.1
Usability
There is a strong association between the service that benefit customers receive
from CMS and their perception of BA. Pathway will ensure that the service
levels provided by the public face of CMS (card issue and collection, use of the
help desk and the process for lost, stolen and damaged cards) will live up to the
high standards of quality and customer service already provided by BA.
One of the critical success factors of this procurement is the gaining of public
acceptance for a card-based payment system. Pathway will use the primary
market research and the application of quality methods to ensure that end-to-
end system usability is built in to the service.
Potential for Change
During the life of this procurement, the introduction and use of smart cards will
increase in the UK and some or all of POCL’s clients may wish to take
advantage of their facilities. It may be appropriate to migrate particular benefits
to smart card technology. By exploiting De La Rue’s capabilities in all forms of
card technology and Alliance & Leicester’s innovative developments in customer
service, Pathway will have potential for change designed into the overall service.
The baseline counter infrastructure proposed by Pathway (see Section 4.2.9.2
and Section 4.3.7.3) will support smart cards from initial roll-out.
ISO standards for smart cards are fully defined and published. Application
standards are soon to be published by CEN the European Standards
Organisation. Pathway expects that the EMV joint specification issued by
Europay, MasterCard and Visa to be influential in developing the use of smart
cards in the UK’s financial sector.
Pathway is uniquely positioned to take advantage of these developments as a De
La Rue subsidiary company will be involved in the definition of the functional
requirements for the UK banks. De La Rue will also be involved in the EMV
joint specification group to promote standardisation of global payment systems.
CARD TECHNOLOGY OPTIONS
The variety of technologies associated with fraud reduction (particularly card
technology) presents BA and POCL with many opportunities in the selection of
the BA card both now and during the life of the procurement contract. The
expertise within the Pathway consortium (in particular De La Rue) has enabled
an objective analysis of the key business and technical trends to take place. A
summary of the following areas is provided ;
* Pathway’s proposal for the BA card
* Magnetic Card Technology
* Smart card Technology
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 23 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.7.5.2
4.2.7.5.3
4.2.7.5,4
4.2.7.5.5
* Options for Fraud Reduction
* Migration
Annex 9 contains a more detailed discussion of these issues and also a complete
set of card specimens that Pathway can offer. The different features and
functions of these card types and the roles they play in Pathway’s migration
strategy for cards is fully explained in this Annex.
Pathway’s Proposal for the BA Card
Pathway proposes that the BA card should be a valueless token. It will be a
magnetic stripe card with appropriate security facilities encoded on the stripe, a
paper signature panel and embossed printing.
This decision is based on a pragmatic assessment of the costs and risks
associated with the various technologies. This initial position provides the best
compromise between the following constraints :
* Economic : what is the best ratio for card cost versus security
* Ergonomic : the requirement to deliver benefit payments effectively
* Availability : the same IOP procedure must be available to all post office
locations
¢ Reliability : The service must be reliable and upgradable
Magnetic Stripe Cards
Magnetic stripe technology has matured to such an extent that most people now
use it in one form or another. It is a simple, reliable, and widely understood
technology. The increasing use of electronic terminals at the point of sale means
that the magnetic stripe is now used for data capture in preference to the
embossing features.
(a) Advantages for BA/POCL :
* Proven technology (25 years of experience and infrastructures)
* Robust (reliable, durable, flexible)
* Readily available from manufacturers and suppliers
* Inexpensive by comparison to smart cards
* International standards exist (also compatible with laser engraving)
(b) Disadvantages for BA /POCL :
¢ Growing vulnerability to fraud through illegal reading of card data
* Limited data storage space
* Data on the stripe can be erased by household objects including fridge
magnets
* No secure upgrade path is available
Smart Cards
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 24 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4,2 - SERVICE ARCHITECTURE
4.2.7.5.6
4,.2.7.5.7
The smart card market is still developing, particularly in the banking field.
Outside the financial industry, smart cards are already widely used in a range of
high-volume applications which includes Pay TV, healthcare, mobile
communications, telecommunications and Utilities. Pathway recognises that
high-profile smart card initiatives such as the Shell loyalty scheme and the
Mondex (electronic purse) pilot in Swindon are making the public more aware
of the potential uses of smart cards,
(a) Advantages for BA/POCL
* Ideal technology to introduce a biometrics for cardholder verification
including digitised signature or photograph
¢ Provides opportunities to develop a more flexible solution to benefit
encashment
¢ Data storage capacity and resistance to fraud/counterfeit is significantly
greater
* Adaptability of the card would allow the delivery of new
services/applications
* Standards exist for smart cards in payment systems (1994 EMV Joint
Specification)
(b) Disadvantages for BA/POCL
¢ Higher initial investment required
* This technology may not prove suitable for all customer groups
* The smart card market is still emerging
Options for Fraud Reduction
Some of the fraud issues influencing the choice of card and card holder
verification are presented in the following sections.
(a) Background to plastic card fraud
Today in the UK plastic card fraud levels have been reduced by almost 40%
since the peak years of 1990 and 1991. Initiatives driven by APACS and
the UK’s banks and building societies have proved successful in reducing the
levels of fraud. More alarming however, is the rise in plastic card
counterfeiting which has increased by nearly 10 times in the same period.
The UK banks along with the rest of Europe are preparing to embrace smart
card technology. This technology is not only seen as a solution to defeat
fraudsters and counterfeiters but also as a means of delivering new value
added services.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 25 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ty te
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.7.5.8
4.2.7.5.9
(b) Cardholder Verification Method (CVM)
Various methods for verifying customer identity are available including :
(1) Signature strip. This approach is simple and well understood.
(2) A PIN system. Pathway believes this would be unsuitable for some user
groups.
(3) Photocards. Pathway’s research (See Annex 8) suggests that the use of
photocards is broadly acceptable but care would have to be exercised
with some customer groups.
(4) Biometrics using a smart card. This would undoubtedly provide the
most reliable method of CVM. The major drawback to its early
introduction is the scale and cost of collecting the required data,
including signature of record and photograph.
The use of biometrics would have to be phased in over a period of
time, having first ensured that the maximum data-collection and use
requirements have been considered for all uses of the card. In addition
a continuing problem with biometrics is the unacceptable level of false
accepts and false rejects.
(c) Counterfeit cards
Traditional security features will be used to counter the threat of counterfeit
cards. These features include :
* The use of a Sherman security value on the card (See Section 4.4.4.4.3)
* Card inspection when presented for benefit encashment
Pathway has identified that magnetic stripe cards will be prone to the same risks
as bank cards and therefore supports a migration to smart cards as this will
reduce significantly counterfeiting.
Migration
Pathway’s fraud reduction strategy is committed to enabling BA to migrate the
benefit payment system from its present reliance on paper to a more dynamic
system that initially uses magnetic stripe card technology. Further developments
could include more advanced magnetic cards using laser-engraved signatures and
photographs, and the introduction of smart cards.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 26 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4,2.7.5.10
4.2.7.5.11
4.2.7.5.12
4.2.7.5.13
4.2.8
4.2.8.1
4.2.8.1.1
4.2.8.1.2
4.2.8.1.3
4.2.8.1.4
Pathway is committed to enabling the introduction of evermore sophisticated
techniques to stay one step ahead of the fraudster. This strategy will enable
further fraud reduction to be realised by addressing the two key areas of
exposure within encashment fraud, namely cardholder verification and
counterfeit or forgery of the IOP.
Pathway’s migration strategy to new fraud-resistant technologies will ensure that
the best and most cost-effective methods are used to authenticate the card and to
verify the identity of the cardholder.
The move from a magnetic stripe IOP to a smart card will provide a means to
upgrade the security of benefit payments. The cost of this migration cannot be
justified on fraud alone but on the added functionality which smart cards can
provide by using verified card-based data such as identification, benefit status,
Utility details. Despite the initial investment costs for BA/POCL this added
functionality can be delivered more cost-effectively with smart cards than any
other proposed IOP format.
If BA/POCL are to realise the business opportunities and service benefits arising
from the migration path then they will have to align themselves with a Service
Provider capable of delivering a seamless and managed migration path within
the desired time constraints. Pathway is such an integrated Service Provider.
TRANSACTION MANAGEMENT SERVICE
TMS OVERVIEW
TMS provides a secure and efficient mechanism for linking POCL clients to
counters. This will be achieved by providing a scaleable, fault-tolerant and
secure environment for routing messages and files. Pathway proposes that the
internal structure of TMS is provided by the Riposte messaging software.
Riposte provides detailed time-based logging of all counter transactions.
Riposte is used within the existing ESNS application and An Post systems.
TMS will operate to a number of different service levels depending on the
nature of the transaction it is supporting and will manage the network
connections such that the transaction flow between the counter and the client
systems can be real time, bulk transfer or trickle-feed.
Components of TMS run on the counter infrastructure and on a number of
central servers, known as correspondence servers, which form the core of the
Transaction Management Service. The scope of TMS is presented in Fig. 8.
Message routing and data file distribution are spread across this layer of
correspondence servers, which are linked by high-speed LANs to form a resilient
backbone. Journal files of all transactions and system events are maintained,
providing audit trails and data stores for system recovery and enquiries.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 27 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
_
zal] I
x
TMS Scope
meesge ut
Ge data le detibution
‘a \
sysens ene
Management a —,
Fig. 8 - Scope of TMS
Functions of the Correspondence Server Layer
4.2.8.1.4 The functions provided by the correspondence server layer include :
* Distribution of payment data and other files to the relevant post offices to
allow card-based payments to be made
* Capture of all messages related to benefit payments, bill payments and other
applications
* Replication of messages across nominated correspondence servers to support
back-up and recovery facilities
* Broadcast facilities between correspondence servers and over the WAN to
post offices, to support enquiries and other on-line transactions such as
foreign encashments
* Software agents to provide transaction details and other on-line transactions
* Archive of transactions for retrieval and subsequent off-line storage
Functions of the Local Layer
4.2.8.1.5 The major functions of the local layer are to :
* Support the counter interface services (see Section 4.2.9)
* Capture of all transaction details to support reconciliation and audit
* Replicate transaction messages to all other office workstations to support
back-up and recovery
* Replicate (on-line or trickle-feed) of transaction messages to the
correspondence server layer to support central functions and to provide
additional recovery facilities
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 28 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.8.1.6
4.2.8.2
4.2.8.2.1
4.2.8.2.2
4.2.8.3
4.2.8.3.1
« Store of payment files in a secure manner for local authorisation of payments
and continued operation of the BPS in the event of network or central system
component failures
A generic POCL interface
Pathway will develop a set of generic TMS software agents which will control
the processes concerned with client data receipt and delivery and transaction
archiving. The development of these agents together with the transaction
interfaces provided at the counter will provide a generic set of interfaces for use
by all POCL clients. A wide variety of clients are already supported by An Post’s
implementation including batch services (for Utility bill payments) and on-line
services (for links to National Savings).
PATHWAY PROPOSAL FOR TMS
TMS will be based on the Riposte product set from An Post/Escher operating
under Windows-NT. It provides a distributed, replicated message-based
architecture. This architecture provides a high degree of resilience at very low
cost. Riposte is a proven product that extends the design principles used in
typical retail systems to operate effectively across thousands of locations.
Riposte will operate at two physical levels. The local layer operates on the PCs
in each post office and provides fail-safe transaction replication and
management at all counter positions. The central layer operates on a number of
central servers which links all post offices together to a provide a seamless, fully
resilient nationwide network.
TMS OPERATIONAL CHARACTERISTICS
The operational characteristics used as input to the design of TMS and the
choice of Riposte are listed in the following table.
This TMS process : Has these operational characteristics :
Bulk Data handling - covers the I Between 1.5M and 6M payment records to
secure and reliable distribution _I be distributed: daily to 20,000 post offices
of bulk data to and from the
counter infrastructure
Real time links to client systems I To cover exception conditions for BA
- covers the support of a time- transactions including :
critical transactional service * urgent payments (approximately 0.5%)
between client applications * foreign payments (approximately 4% -
within the counter infrastructure 10%)
and server systems within or * payment enquiries
external to the Procurement * stop notices (approximately 6%)
Service Boundary
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 29 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.8.4
4.2.8.4.1
4,.2.8.4.2
4.2.8.4.3
4,.2.8.4.4
4.2.8.4.5
[ ‘This TMS process ¢ Has these operational characteristics :
Trickle-feed - enables small I To enable encashed and expired BA
batches of transaction data to be I payment details and bill payment records
fed from the counter to be returned from all post offices during
infrastructure and client I the day
applications, typically during the I
working day
Data archive - enables the To enable periodic archives to be taken of
selective storage of transactions I all transaction data from TMS for storage
for subsequent retrieval on on-line and progressively off-line media
TMS SERVICE QUALITIES
The service qualities which were considered as part of TMS design and which
have influenced the choice of environment for TMS are discussed in the
following sections.
Security
TMS will apply different levels of security control to the data within its domain
depending on the security classification of the transaction or data type.
Pathway’s design and implementation of TMS will use data security measures
including CRCs and digital signatures to protect all data within the system from
unauthorised modification. In addition data encryption can be selectively
applied within TMS as needed. The security facilities within Riposte are
described in detail in Section 4.3.4.8.
Performance
TMS will support a wide range of transaction types, each with different
requirements for storage and onward transmission. In some cases performance
will be determined by the service requirements of the specific POCL client. In
other cases the inherent requirement for a robust and resilient service will
influence how, where and when data is moved by TMS.
TMS will be capable of optimising the movement of data between customers
and clients, according to the required service levels. These will include the on-
line placement of stop notices, the 30-minute cycle for emergency BA payments
and the daily bill payment details required by the Utilities.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 30 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
A
SECTION 4.2 - SERVICE ARCHITECTURE
Potential for Change
4.2.8.4.6 The transaction profiles currently identified by BA and POCL may change over
time. For example, an increase in the number of on-line services to POCL
clients or an increase in the volume of data associated with each transaction.
Pathway’s design for TMS is both modular and hierarchical in order that growth
can be accommodated without risk, and to ensure that changing transaction
patterns do not jeopardise existing services.
4.2.9 COUNTER INTERFACE SERVICE
4.2.9.1 COUNTER INTERFACE OVERVIEW
4.2.9.1.1 The Counter Interface Service comprises the range of hardware and software
components (known as the counter infrastructure) that will be installed in each
post office to meet the requirements of POCL’s counter automation strategy.
This is shown in Fig. 9. Pathway’s baseline counter proposal will meet the
functional requirements of the benefit payments, bill payments and EPOS
applications and provide a growth path for additional client transaction types in
the future. The software architecture used within the counter interface will
enable the baseline hardware proposal to be enhanced to provide increased
peripheral functionality if required.
Branch ISDN Nework
s a
<<] Jounal
hie Payment Files
System 8 Application Files
‘Counter Payments
Bill Payments
Security
User lmeface i
Application framework
Application development tools I I *
ae I
sag stipe card wader bar code
smartcard reader cheque validation printer
bar code reader weigh seales
OCR AB reader pass book printer
tally roll printer
inkje/matex printer (back-office)
Fig. 9 - Scope of Counter Infrastructure
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 31 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.9.1.2
4.2.9.1.3
4.2.9.1.4
4.2.9.1.5
4.2.9.2
4,.2.9.2.1
4.2.9.2.2
Part of the Riposte product set, the Riposte Desktop, provides a framework for
the easy and consistent development and implementation of complex financial
transactions. Desktop supports state-of-the-art interface controls (action lists,
on-screen keyboard, buttons, menus, screen help) which enable transactions to
be presented to counter staff in an intuitive and consistent way. Desktop also
supports Rapid Application Development (RAD).
The counter applications proposed by Pathway will be constructed in sets which
allow generic transactions to be built. Section 4.3.3 describes Pathway’s
proposal for the construction of generic transactions.
Each workstation in a post office runs a journal server which manages the
journaling, retrieval and data replication functions at the local level.
Key functions of the counter infrastructure are :
* To provide access control, user authorisation and password security
* To present transactions to counter staff in an intuitive fashion
* To support a wide range of peripherals needed to enable electronic
transactions
* To manage journaling (audit trail) and data replication at the local level
* To manage communications with the correspondence server (components of
journal server exist on all workstations in the workgroup although one
workstation normally handles all the WAN functions)
* To administer data integrity (through CRCs and data encryption) as required
* To check that distributed files have not been tampered with by using digital
signatures
¢ To provide uninterrupted payment authorisations in the event that
communications to the central location are not available
PATHWAY PROPOSAL FOR THE COUNTER INFRASTRUCTURE
Pathway’s proposal for the counter interface covers the counter hardware and
operating software, the counter peripherals and the application software for
benefit payments, bill payments and EPOS.
Counter Hardware
The baseline counter hardware will comprise industry-standard 486-PCs
running Windows-NT. The counter peripherals will include 9’ colour monitor,
keyboard, reading devices (magnetic card, smart card and OCR) and a counter-
top receipt printer. A printer for back-office tasks will be provided for each post
office.
Pathway will ensure that all units are compact and acceptable to users, and
where feasible will provide combined-function units such as a single device
incorporating all electronic reading functions. This will minimise the counter
space requirements.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 32 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.9.2.4
4.2.9.3
4.2.9.3.1
4.2.9.4
4.2.9.4.1
4.2.9.4.2
Counter applications
The counter applications will all be based on the generic transaction set
supported by Riposte and will draw on the proven capabilities of the
CounterAction system in use in An Post. Details of this project are presented as
a case study in Annex. 6.12 - An Post CounterAction. The counter applications
will consist of :
* Benefit Payments - Order Books. This will be based on the existing ESNS
system
* Benefit Payments - Electronic Payments. This will be developed from the
existing card based benefit payments application in use in An Post
* Bill Payments. This will be developed from the existing bill payments system
in use in An Post
* EPOS. This will based on the developments currently underway for the
Singapore Post Office
COUNTER INTERFACE SERVICE OPERATIONAL CHARACTERISTICS
The operational characteristics considered as part of the selection and design of
the counter interface are presented in the following table :
This counter interface process: I Has these operational characteristics :
Transaction activation Must be capable of supporting a wide
variety of peripherals
Transaction presentation Must be capable of being used by a wide
variety of post office counter staff
Transaction execution Must provide the fastest possible
transaction time
Back-up and recovery Must complete unaided or with minimal
human intervention
Payment authorisation Must be available in the event of central or
network component failures
COUNTER INTERFACE SERVICE QUALITIES
The counter interface qualities which were addressed during the selection and
outline design phase are considered in the following sections.
Usability
Acceptability and usability of the counter interface by post office counter staff
represents two of the major elements in ensuring a successful and efficient
service. The counter applications provided by Pathway will be produced with
an intuitive user interface which will facilitate user acceptance and minimise
training requirements.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 33 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.9.4.3
4,.2.9.4.4
4.2.9.4.5
4.2.9.4.6
4.2.9.4.7
4.2.10
4.2.10.1
4.2.10.1.1
Pathway will seek to actively involve the counter staff community in the
customising the counter interface and in the final selection of counter
infrastructure. Pathway’s objective is to ensure that users are effective in
carrying out their work, are efficient in terms of their time and effort, and are
satisfied with the system’s physical attributes and appearance.
Availability
Pathway has identified that a guarantee of benefit payment is a primary
requirement and consequently all service components will contribute to
achieving this objective. The design of the counter interface will ensure that the
failure of a counter position will not prevent the post office from providing the
BPS. The counter interface will automatically recover from any failure of a
counter position with no loss of transaction data.
If communications with the central system are not available, then payment can
continue uninterrupted (for up to 2 days) for customers who are associated with
the local nominated post office. This is possible as payment information is
stored locally. Fall-back procedures (described in Section 5.5) will enable
foreign encashments to continue in this scenario.
Security
The user interface supports differing user roles together with full password
controls, Specific user roles (SUPERVISOR and TELLER) will be provided to
ensure that specific counter applications and data are only accessed by
authorised users.
Potential for Change
The introduction of additional client business is recognised by Pathway as a
major POCL objective. The design of the counter interface will enable business
opportunities to be realised quickly and introduced into the Post Office network
with a minimum of cost and disruption. By providing an industry standard
software and hardware infrastructure Pathway can ensure that the counter
interface will readily accommodate new services and peripherals including
electronic weigh scales.
OPERATIONAL SUPPORT SERVICES
OSS OVERVIEW
The Operational Support Services consist of an initial set of systems to assist the
Postmaster in the management of his post office and to provide central
information and reporting for POCL. These services will be provided in part by
back-office systems running within the local post office and in part by central
service functions which together will cover the end-to-end service requirements.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 34 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.10.1.2
4.2.10.1.3
4.2.10.2
4,.2,10,2.1
4.2,10,2.2
4.2.10.3
4.2.10.3.1
Central Service functions
The following system functions will be provided by central management
information systems :
* Central cash management
* Central stock management
¢ National Cash Account reconciliation
* Other management information
Back-office functions
Back-office functions will be provided at the local post offices by the counter
infrastructure itself, or by using application packages that access the captured
data. These back-office functions include :
* Local cash management
* Local stock control
* Local Cash Account and office balancing
* Postmaster remuneration
PATHWAY’S PROPOSAL FOR OSS
Pathway will develop the applications required to meet the OSS requirements.
The local applications will, in part, be based on the functionality already
available from An Post.
The central systems will be developed by Girobank using their specific expertise
in reconciliation and cash management.
OSS OPERATIONAL CHARACTERISTICS
Pathway has identified the following operational characteristics which must be
provided by the OSS. These characteristics have been used as part of the input
to OSS selection :
This OSS process : Has these operational characteristics :
Postmaster remuneration - covers I Each post office will use a formula to
the calculation of fees payable for I calculate ‘unit credits’ based on transaction
all transactions completed over type. Both electronic and non-automated
the counter transactions will be supported.
Information will be provided locally and
transmitted to POCL via TMS
Cash account reconciliation - Each post office will capture transaction
covers the automated production I type and value and produce a weekly Cash
of a Cash Account Account. This will be transmitted to
POCL via TMS
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 35 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.10.4
4.2.10.4.1
4,2,10.4.2
4.2.10.4.3
4.2.10.4.4
4.2.11
4.2.11.1
4.2.11.1.1
This OSS process : Has these operational characteristics :
Reporting and MIS - systems to I Daily and weekly reports produced in each
provide local and central sales, post office and centrally
service and contribution analysis
OSS SERVICE QUALITIES
The OSS covers both central and local functions. The operational service
qualities are different for both locations. The service qualities are listed below :
Usability
The local OSS functions (for Cash Account production, balancing and
transaction analysis) will be easy to use and operate with the minimum of delay
since they will typically be run at end-of-day. The local OSS functions will use
the same intuitive and proven counter interface as is proposed for all counter
applications.
Availability
Both central and local OSS services must operate within acceptable levels of
availability. The resilient design of the counter infrastructure will ensure that
local OSS services, have the same high levels of availability as the counter
applications. Central services will be supported on resilient hardware to ensure
maximum service availability.
Security
Both central and local OSS must operate with a high degree of security. The
security will be provided using the resilient counter environment for local OSS
and by the security inherent within TMS and the central computing platforms.
THE NETWORK INFRASTRUCTURE
PATHWAY’S PROPOSAL FOR THE NETWORK INFRASTRUCTURE
Pathway is working with BT, who have been given responsibility for designing
the Branch Wide Area Network which will link all post offices with the centres
of operation. Investigations have shown that Integrated Services Digital
Network (ISDN) is the preferred network architecture to support the Pathway
service architecture and the distributed authorisation service. ISTN provides
high reliability, low error rate, fast connection time and high bandwidth. ISDN
will achieve 100% geographic coverage by early 1996.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 36 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
eS ¢
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.11.1.2
4,2.11.1.3
4,2.11.2
4.2.11.2.1
4,.2.11.3
4.2.11.3.1
Pathway recognise that certain high useage or low useage post offices may justify
alternative network connections (i.e. permanent circuit or PSTN). These will be
determined following discussions on expected transaction volumes with POCL.
Through BT’s Communications Management division, Pathway can offer a
managed service covering all of these network options and including PSTN calls
to the Pathway Call Reception Centre for help desk support.
Pathway’s proposal for the network infrastructure is based on a design across
three levels as shown in Fig. 10. The network infrastructure for each of these
levels is described below.
Correspondence Server
‘Backbone Network
Bien
ZS Correspondence
Servers
Beanch Wide Area Network
— moe Fost Office Local LAN
10Base -T LAN Othe PO
a o> ss
Fig. 10 - Pathway Network Infrastructure
POST OFFICE LOCAL AREA NETWORK (LAN)
Post offices with multiple PCs will have LANs. These will support automatic
data communication between PCs in the post office, enabling all PCs to
communicate with the branch network through the communications PC. This
PC will contain an ISDN card. The LAN will also enable central systems
management tools to monitor activities on individual PCs.
BRANCH WIDE AREA NETWORK (WAN)
The branch WAN connects all the post offices to the central systems. This will
be based on the modern ISDN system. This will be provided by BT whose total
quality services cover the design, marketing, sale, provision, operation and
maintenance of telecommunications networks throughout the UK.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 37 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.11.3.2
4.2.11.3.3
4.2,11.3.4
4.2,.11.3.5
4.2.11.4
4.2.11.4.1
Each post office will have an ISDN 2 link to the branch network, giving each
office two high-speed channels (2 x 64 kbit/s) for data, or voice traffic (very
large post offices may have a second ISDN 2 line). The correspondence server
backbone network will support multiple ISDN 30 connection points spread over
4 locations (each providing 30 channels) to ensure ample channels are available
to support post offices during peak periods.
The technology is well proven and provides very clean, efficient and reliable
communications links for data, voice, text and graphics. With ISDN 2, dialled
calls can be made to other devices on ISDN 2, ISDN 30 or analogue PSTN lines.
Depending on needs, up to 8 separate pieces of equipment such as PCs, digital
telephones, fax or video conferencing terminals, can be connected to a single
ISDN 2 line. Up to two of them can be used simultaneously. It has ample scope
for growth and is inherently resilient through techniques such as diverse routing,
automatic transfer of calls to an alternative answering point if the ISDN lines are
busy or an integrated services private branch exchange fails,
ISDN provides a particularly good fit to the style of working within post offices.
The fast call set-up, fast and reliable operation lends itself to short calls being
made during typical counter operations without any perceived delays. Lines do
not have to be kept open while lengthy transactions are completed, and a tariff
structure based on per-second charging means that call charges are kept to a
minimum. The high speed available with ISDN means that additional benefit
can be achieved by saving non-urgent data within the POCL counter
infrastructure until connections have been established for an urgent
transmission, and then transmitting a small burst of this data on the back of the
primary transmission. This technique is referred to as trickle-feeding
transactions,
TMS enables all transactions to be given priorities, which include : urgent,
which activates an on-line query, non-urgent, which will transmit the transaction
by trickle-feed or end-of-day which ensures that all transactions are replicated to
the central location. While supporting trickle-feed, TMS will open a line every
few minutes in the absence of an urgent transaction (the period can be
predetermined for each post office). This ensures each line is monitored
regularly and that the correspondence servers remain synchronised with the post
offices. This technique is highly efficient, tailorable (by re-defining the priorities
of individual transactions), and exploits the high speed and the tariff structure of
ISDN.
CORRESPONDENCE SERVER BACKBONE NETWORK
This a high-speed, secure network that acts as the focal point for all the post
office connections. It connects all the correspondence servers, which by using
Riposte, provide a transaction management capability together with a high
degree of resilience. It gives access to any correspondence server from any post
office (and vice versa).
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 38 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4,2.11.4.2
4.2.12
4.2.12.1
4.2.12.1.1
4.2,12,1.2
4.2.12.2
4.2.12.2.1
The ability of correspondence servers to replicate data and select optimum data-
transfer routes will be exploited by distributing the backbone network physically
across a number of major nodes. Correspondence servers within each node are
inter-linked on high-speed networks such as FDDI, and the nodes are
interconnected by high-speed BT services such as Megastream or SMDS.
SERVICE BOUNDARIES AND INTERFACES
INTRODUCTION
Pathway’s strategy for the service architecture is to provide a set of service
components with well-defined interfaces which will be used together to provide
end-to-end service delivery between POCL clients and their customers.
The service boundaries and interfaces will be explicitly defined and service level
agreements formed to ensure that all parties (both within Pathway and between
Pathway, BA and POCL) and have a clear understanding of their role and
responsibilities in the provision of end-to-end services.
SERVICE INTERFACES
Each of the primary service interfaces shown in Fig. 11 is summarised below.
Procurement Service Boundary
ae
\ LY ‘Operational I
7” POCL STRATEGIC ‘Support nN J
ee
/ J Yemenice
Fig. 11 - Service Interfaces
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 39 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.12.2.2
4.2.12.2.3
4.2.12.2.4
4,2,12.2.5
4.2.12,2.6
4.2.12.2.7
4.2.12.2.8
4.2.12.2.9
Interface 1: CAPS-CMS
This supports the transfer of new and amended cardholder information using
file transfer. The question of referential integrity between CAPS or other BA
customer database will require discussion and agreement. As a guide, it is
assumed that CAPS is the master source of all information relating to the
customer except card-related data. All amendments other than card details will
always be supplied via CAPS. This includes name, address, and nominated post
office.
Volumetric information applicable to charging will be derived from counts of
new and amended card details passed from CAPS.
Service level data relating to the interface will include CMS service availability
for processing CAPS files and processing time as a component of the end-to-end
card issue service.
Interface 2 : BA Offices-CMS
This supports interactive access from BA to enquire about customer card status
and place restrictions or stops on card usage. CMS can provide this access for
BA staff, subject to appropriate security constraints, although further discussion
will be required on the technical options for implementing communications such
as decisions on protocols and network routing.
Volumetric information relating to interface usage will be derived from counts
of transactions types entered across the interface.
Service level data relating to the interface can include service availability,
response times for enquiries and acceptance times for the processing of card
stop requests.
Interface 3 : CMS - Card Production
This is an internal Pathway boundary between the card management and card
production and delivery processes. It will utilise a secure communications link
between Pathway’s subcontracting organisations. Separate service levels for card
production and delivery are identified in Section 4.5 SR 4.23, as components
within the end-to-end service for new and replacement cards.
Interface 4 : CAPS - PMS
This interface supports file-based transfer of payment authorisation files to PMS
and of payment encashment and expiry files to CAPS. In addition a transaction-
based interface service will support urgent payment authorisations, payment
stops, and enquiry transactions from CAPS to PMS. Other transaction
notifications from PMS to CAPS to support card usage alerts and payment
encashment alerts will require similar facilities.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 40 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4,2,12.2.10
4,.2.12.2.11
4,2.12.2.12
4.2,12.2.13
4,2,12.2.14
4.2,12.2.15
4.2.12.2.16
4,2.12.2.17
It is envisaged that control totals will be used across this interface to detect
discrepancies. Detailed validation requirements and exception procedures will
be agreed between Pathway and BA. Further discussions will also be required
on the technical communications options for supporting these flows.
This boundary must support transaction reconciliation between the parties and it
is proposed that all operations across this interface be logged, in addition to the
maintenance of an auditable database of the status of all payment authorisations
and associated encashment (or expiry).
Transaction-based charging information will be derived from the use of this
interface, specifically relating to the number of payments made, broken down by
benefit type and timeliness (urgent/routine). Other factors include the number
of enquiries made and the number of reports produced.
Service levels relating to the use of this interface are based upon the availability
of the PMS service and its performance (response/throughput) as a component
of the end-to-end Payment Authorisation Service.
Interface 5 : CMS - PMS
This interface is internal to Pathway and provides a formal boundary between
the card and payment management services. The two functions supported are :
a) PMS access to card verification data during the processing of payment
authorisation data prior to its distribution.
b) A transactional interface to enable CMS to report card stop or monitoring
events requiring an immediate update to the status of authorised payments.
Interface 6 : TMS - Central Services
This interface is designed to support generic operations between TMS and all
central services (CMS, PMS, Value Added applications and central OSS
applications) as well as to the various POCL clients and internal systems.
The TMS architecture supports a range of generic software agents to transfer
information to and from TMS via the Riposte API. These include functions for
file transfer and real time transactions. The Riposte API provides facilities for
the use of retrieval indexes to support the extraction of information according
to the needs of the particular host application.
Generic agents can be customised by the use of parameters to the needs of the
individual, central or client applications or by adding the appropriate file
transfer or transactional support. This will include support for XCOM, FIP or
agreed alternatives to enable files to be transferred between TMS and the Host
Polling Centre. This interface will be subject to service level constraints and
reconciliation needs.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 41 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.12.2.18
4,2.12.2.19
4.2,12.2.20
4.2.12.2.21
4,.2.12.2.22
4.2,12.2.23
4,.2.12.2.24
4.2.12.2.25
Pathway will use the TMS interface to extract information on transaction
volumes and to provide audit and archiving facilities.
Interface 7 : Counter Interface - TMS
This is an internal Pathway interface to support the transfer of information
between TMS and the counter interface. This interface is designed to be generic
for all counter or back-office applications, using the Riposte API to support file
and transaction operations. Transactions are automatically replicated to provide
back-up and recovery. By specifying message priority, transaction replication to
TMS and file transfer operations can be immediate, trickle-feed or deferred to a
time deadline, typically end-of-day.
Interface 8 : Card Production - Post Offices
This is a procedural interface supporting the transfer of benefit cards between
the card production service and post offices, where they are stored for
subsequent issue to customers in accordance with the counter procedures. This
interface will form part of the end-to-end service for card issue and will require
agreement on security procedures for acknowledgement of receipt of card
batches and their safe storage.
Each card batch will be bar-coded and this information will be read and
returned to CMS to register receipt.
Interface 9 : Counter Interface - Post Office Clerk
This interface is the Human Computer Interface (HCI) between the counter
infrastructure and system users within the post offices. Pathway proposes that a
generic approach is used, based upon the graphical user interface style adopted
for the ESNS application. This is built upon the Riposte Desktop, with the
extensive use of peripheral-driven operations to minimise the use of the
keyboard.
All counter and back-office applications within the Pathway proposal are based
upon a generic HCI. We would expect to discuss and agree the details of the
specific HCI components during the prototyping and demonstration phase and
document this in an HCI style guide which will be used for all counter
application development.
The baseline proposal incorporates a standard colour monitor, with the option
of touch screen operation as an efficient alternative to keyboard usage. The
HCI will support both options.
Service levels to be agreed will include discussion on availability and transaction
performance.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 42 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.12.2.26
4.2.12.2.27
4.2.13
4.2.13.1
4.2.13.1.1
4,2.13.1.2
4.2.13.2
4.2,.13.2.1
4.2.13.2.2
Interface 10 : Benefit Customer - CMS
This interface allows the customer to report loss, theft or damage of cards to
CMS via the help desk. It also supports the distribution of pick up notices to
benefit customers.
Service levels will include an assessment of the system performance and help
desk response.
PATHWAY SUPPORT SERVICES
INTRODUCTION
Pathway will implement a set of support services to manage the availability and
service quality for both the current and future service requirements. The
principal services required for steady state are help desks and overall systems
management.
These will be supplemented during the roll-out by a range of training and
specialist support services. These are described in Section 5 Steady State
Services and Section 7 Roll-out and Implementation.
HELP DESKS
Help desks are needed for a number of specialised areas, for example : card
management, post office support for the software application, hardware
support, and installation teams during the roll-out.
All calls will be handled through a single point of contact, the Pathway Call
Reception Centre (PCRC), where the caller may ask for advice or for fault
resolution. The PCRC confirms the identity, location and nature of the call, and
the caller’s entitlement to assistance. For example, a member of the public will
have access only to the CMS help desk. The call is then automatically routed to
the appropriate specialised help desk. An overview of Pathway’s help desk
structure is shown in Fig. 12.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 43 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4,2.13.2.3
43.13.24
4.2.13.3.1
Help Desks
BA Customers a
ub I ar) MS
4 Benefit
Payment
BA Help Line
if le. I Services
POCL Help Line Call
EB Reception, eo
Transfer & Hardware
BA Staff Tracking I [
I All Other
a Software) poct,
Services
POCL Staff
Pathway Call
Reception Centre
Fig. 12 - Pathway Call Reception Centre
Individual help desks will be backed up by support teams. The service
management function covers configuration management, change requests,
training, documentation requests, and so on.
Key functions of Help Desks
The key functions that will be provided by the help desks include :
* Call security identification
* Call categorisation, prioritisation and registration
* Progression to appropriate help desk or direct to support team
* Call follow-up and automatic escalation
¢ Regular reports (statistics, performance against SLAs)
« Ad hoc reports
SYSTEMS MANAGEMENT
The systems management functions consist of monitoring the in-built integrity
features on all the managed components of the service, and checking that the
operational processes are working effectively and efficiently. The major service
areas include :
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 44 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
1. Daily operational control
2. Help desk support
3. Operational statistics
4. System security
5. Configuration management
6. Software distribution
7. Change controls
8. Billing and service level
The day-to-day operational control of the
distributed system components (the
equipment at the post offices, the networks,
the correspondence servers) and the central
system components including PMS, CMS
and links to client systems.
The recording and progression of
problems.
Covers operational statistics on transaction
types and volumes, system incidents,
resource usage and performance (deadlines
and responses).
Covers auditing of the privacy and security
aspects of the system, data back-up
recovery and archiving.
Needed on all components.
Installation and configuration version
control.
This covers the controls needed for system
enhancements, post office changes and new
installations during the roll-out phase.
Relates to contract management and service
reporting level agreements.
4.2.14 SUMMARY
4.2.14.1 Pathway has analysed the performance characteristics and service qualities
required for each of the components of the service architecture. Using the
results of this analysis Pathway has created a design which is resilient, secure and
extensible. The service architecture proposed by Pathway is cost effective both
in terms of initial investment and ongoing operation.
4.2,14.2
Pathway has chosen a centralised Payment Management System and a
distributed authorisation service for the Benefit Payments Service. No single or
multiple infrastructure failure can completely disrupt the BPS.
As a result
Pathway guarantee the payment of benefit to legitimate customers at all times.
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE
Page: 45 of 46
Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.2 - SERVICE ARCHITECTURE
4.2.14.3
4.2.14.4
4.2.14.5
4.2.14.6
4.2.14.7
The architecture has unique advantages in terms of its resilience and the low cost
associated with extending the infrastructure at the point of service delivery.
This includes the addition of new post offices and increasing the number of
counters at particular offices. This extensibility will support business-volume
growth without major impact within the overall end-to-end service.
By using generic interface components at all levels, the architecture will support
new business development without the need for large-scale developments at any
point within the service architecture.
Pathway’s design is based on the extensive and unique knowledge that Pathway
brings to the business and service requirements of BA and POCL. It is also built
upon an in-depth understanding of the social environment within which these
services will be operating. Customer acceptance issues have been researched by
Pathway and the service architecture has been refined to take account of these
issues.
One component of the service architecture, the choice of benefit card, is a
balance between customer acceptance, usability, cost and resistance to fraud.
Magnetic cards are highly acceptable but as smart card usage grows their
superior capability will be accommodated within the service architecture.
Pathway proposes a workable and low-risk system and service components.
Pathway has a dedicated organisation which will manage each of these system
and service components in a seamless and professional manner to meet the
needs and objectives of BA, POCL, their customers and clients.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 46 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
SECTION 4.3 TABLE OF CONTENTS
4.3 POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.1 INTRODUCTION ... aetna
4.3.2 SUMMARY OF POCL STRATEGIC INFRASTRUCTURE PROPOSAL.
4.3.2.1 INTRODUCTION PATHWAY’S STRATEGIC INFRASTRUCTURE PROPOSAL .
4.3.2.2 OVERVIEW OF THE TRANSACTION MANAGEMENT SERVICE
4.3.2.3 OVERVIEW OF THE COUNTER INTERFACE.........+++
4.3.2.4 OVERVIEW OF OPERATIONAL SUPPORT SERVICES
4,3.2.5 OVERVIEW OF RIPOSTE ARCHITECTURE .
4.3.3 GENERIC APPROACH ..
4.3.3.1 INTRODUCTION TO PA
4.3.3.2 DEVELOPMENT OF THE POCL GENERIC APPROACH .......«
4.3.3.3 ADVANTAGES OF THE EVOLVED POCL GENERIC APPROACH
4,3.3.4 BILL PAYMENTS......
4.3.3.5 ECCO+ REPLACEMENT.
4.3.3.6 ENHANCED ESNS BENE!
4.3.4 TRANSACTION MANAGEMENT SYSTEM
4,3.4,1 INTRODUCTION TO TMS.......
4.3.4.2 INTRODUCTION TO RIPOSTE
4.3.4.3 RIPOSTE - DESKTOP.
4.3.4.4 RIPOSTE - SECURITY
4,3.4.5 JOURNAL SERVER...
4.3.4.6 KEY FUNCTIONS PROVIDED I BY “JOURNAL SERVER.
4.3.4.7 CORRESPONDENCE SERVER
4.3.4.8 OPERATIONAL INTEGRITY .
4.3.4.9 RIPOSTE - UTILITIES ..
4,3.4.10 VALUE ADDED PROCESS!
4,3,4.11 INTERFACE TO POCL SYSTEMS.......
4,3.4,12 END TO END BILL PAYMENT SERVICE
4.3.5 COUNTER INTERFACE ........0+ 31
4.3.5.1 INTRODUCTION.
4.3.5.2 BUSINESS NEEDS..
4.3.5.3 IMPLEMENTATION OF COUNTER INTERFACE - TECHNICAI
4.3.5.4 SOFTWARE ENVIRONMENT... we
4.3.5.5 DEVELOPMENT ENVIRONMENT ‘AND ‘APPROAC!
4.3.6 OPERATIONAL SYSTEMS SUPPORT
4.3.7 HARDWARE AND PERIPHERALS ...
4,3,7.1 INTRODUCTION TO HARDWARE AND PERIPHERALS .
4.3.7.2 TMS HARDWARE...
4.3.7.3 COUNTER INTERFACE “HARDWARE “AND PERIPHERALS
4.3.7.4 COUNTER INFRASTRUCTURE OPTIONS - F85 TERMINAL.
4.3.7.5 POST OFFICE BRANCH NETWORK .......0+0+4
4.3.8 SATISFYING BA/POCL INFORMATION NEED:
4.3.9 POCL STRATEGIC INFRASTRUCTURE - SUMMARY.
ONNGGANRP RRR
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ON seit
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3
4.3.4
43.1.1
4.3.1.2
4.3.2
4.3.2.1
4.3.2.11
POCL STRATEGIC INFRASTRUCTURE SERVICE
INTRODUCTION
This section describes Pathway’s proposal for the POCL Strategic Infrastructure.
The section is organised to provide an overview of the proposed infrastructure
and follows with a description of the components of the infrastructure in detail.
This section contains the following principal sections :
* An overview of the complete strategic infrastructure proposal and the Riposte
system on which the infrastructure is based
* Pathway’s proposal on the generic transaction approach
* A detailed discussion on the transaction management system and the
functionality provided by Riposte
* A discussion on the counter interface and how the Pathway solution is
suitable for the wide variety of counter staff
* A mapping of the BA/POCL information needs and how they will be satisfied
SUMMARY OF POCL STRATEGIC INFRASTRUCTURE PROPOSAL
INTRODUCTION PATHWAY’S STRATEGIC INFRASTRUCTURE PROPOSAL
It is Pathway’s sole mission and objective to deliver the end-to-end service and
to provide value for money throughout the life of the contract. In providing the
strategic infrastructure for post offices, Pathway will provide competitive
advantage to POCL by enabling POCL to provide improved service to all their
clients and in particular will enable POCL to provide an improved payment
delivery mechanism for benefit payments. Our infrastructure enables POCL to
support all of the current post office products (and is future proofed to support
new products as they are created). The infrastructure also allows POCL to
migrate existing functionality to the new infrastructure. The proposed
infrastructure supports the achievement of the following POCL critical success
factors :
This critical success Will be given this Pathway support :
factor :
Adherence to industry All of the hardware, peripherals and software
standards proposed by Pathway is of industry standard,
giving POCL a high degree of flexibility in the
choice of future counter equipment
Affordability Pathway has chosen a PC architecture based on
Microsoft and Intel products to deliver the
POCL Strategic Infrastructure. This is the most
cost-effective route for processors, related
peripherals and application development
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.2.1.2
4.3.2.2
4,.3.2.2.1
This critical success Will be given this Pathway support :
factor :
Business development Pathway’s proposal will allow POCL to seek out
new business and will encourage clients to
conduct business with POCL, due to the highly
efficient nature of the solution and our capability
for rapid roll-out of new services
Customer service Pathway’s proposal will maintain and enhance
customer service by providing a high level of
accuracy in data capture and by improving the
speed of transactions at the counter.
Profitability Pathway’s solution will contribute to the
profitability of POCL by removing operational
costs and adding operational integrity to the
business environment
Support existing Pathway’s proposal clearly supports the POCL
information strategy Information Systems Strategy
Universality Pathway’s solution can be implemented at every
post office. Pathway can also propose
alternatives as needed, bearing in mind the desire
for the critical success factor of Affordability.
This may be appropriate in small/rural post
offices
Versatility Our proposal allows for the addition of new
peripherals to support new services and as it is
based on the most commonly available hardware
and operating system software, support for
future needs is guaranteed
The transaction management system and the counter interface components of
the strategic infrastructure are based on PC hardware and the Microsoft product
set. The transaction environment is provided by Riposte, which is described in
overview in Section 4.3.2.5.
OVERVIEW OF THE TRANSACTION MANAGEMENT SERVICE
The function of TMS is to accept transaction information from the counter
applications and to provide guaranteed replication of this information at the
central server level. It is also responsible for the distribution of information
from a central location to individual post offices. The transaction details are
captured by counter applications and are passed into Riposte. The Riposte
system ensures that every transaction is executed in an accurate, secure and
auditable fashion.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
Functions provided by TMS
4.3.2.2.2 TMS is responsible for moving data between central sites and the post offices.
Data movement is both inbound and outbound.
Inbound Data Flow
4.3.2.2.3 TMS accepts data from the counter applications. This data is formatted in a
particular format and is passed to the journal message store as a journal message.
Periodically the journal messages are replicated to the central location. The
messages are then passed to client systems following formatting or other
processing.
Outbound Data Flow
4.3.2.2.4 TMS accepts data from client systems at a central location. The information is
then distributed to local post offices and made available to the counter
applications. The information being distributed from the central site includes
payment data, configuration information and information related to variable
prices or rates.
4.3,.2.2.5 Riposte guarantees that the transport of data is carried out in a secure and fully
auditable manner. In particular TMS will provide :
¢ Security of data (digital signature and/or data encryption)
* Recovery and back-up facilities
¢ Interface to client systems
* Interface to counter applications
The TMS and the Counter Interface Boundary
4.3,2.2.6 The boundary between TMS and the counter interface is represented graphically
in Fig. 1 below :
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
¥ +
ft TMS
TMS Si
MS Software Agents Eoewdery
ee Riroste API f
[Correspondence Server
I -—(Central)
“7
ws
Journal Server
+
Applications Counter
: Interface
a aa Boundary
Presentation of Transaction
Peripherals
Fig. 1 - TMS & the Counter Interface Boundary
4.3.2.3 OVERVIEW OF THE COUNTER INTERFACE
4.3,.2.3.1 The counter interface is the means by which the counter staff at the post offices
interact with the counter system. The interface covers the :
* Visible face of the software, which reinforces the counter staff’s conceptual
model of the transactions being executed
¢ Data capture component of the interface, which is the interaction of the
counter staff with the peripherals on the desk
* General human-factor engineering of the entire countertop
¢ Interaction of the counter staff with customers
4.3.2.3.2 Factors that affect the conceptual model include :
* Presentation of information
¢ Readability of information
* Ease of navigation
* Speed of response
* Logic of the approach
* Accuracy of the system
* Ergonomics of the workplace
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.2.3.3
4.3.2.4
4.3.2.4.1
4,3.2.4,.2
4.3.2.4.3
4.3.2.5
4.3.2.5.1
4.3.2.5.2
The counter interface is the visible presentation of all transactions to the counter
staff and customers. The counter interface functions include :
* Provision of an electronic workspace for the execution of counter processes
¢ Provision of security and access controls
¢ Data capture using a wide variety of peripherals
¢ Applications to process the required transactions
OVERVIEW OF OPERATIONAL SUPPORT SERVICES
POCL has specified that the operational support services required as part of the
procurement are :
* Outlet Remuneration and Reconciliation
* Reporting and MIS
Pathway will provide a set of reporting modules at the counter which will
provide summaries of transactions to assist the teller in balancing. A ‘batching’
facility also exists which is used by An Post to produce a summary of each of the
automated products after a certain number of transactions have been produced.
This facilitates balancing by the counter staff.
When all office products are automated the production of the cash account will
be a highly efficient process relying on summaries produced as part of the
counter staff’s end-of-day activities. In the transition period where there are
both automated and non-automated products at the counter, Pathway will
incorporate the functionality of Capture and ECCO+ to enable the cash account
to be produced.
OVERVIEW OF RIPOSTE ARCHITECTURE
While the components of Riposte are described in detail later in this section, it is
useful to give an overview of the overall design at this point, to promote
understanding.
Riposte is implemented as a distributed and replicated message-based
architecture. The Riposte messaging architecture is designed to provide a high
level of resilience at very low cost. This is achieved by using a peer-to-peer
messaging protocol to maximise system availability and reduce overall cost of
ownership by using widely available hardware and industry-standard software
components. The system consists of two layers which are presented graphically
in Fig.2 below :
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
‘LAN
Correspondence Server Layer
4
/ ‘Office LAN _ Office LAN
i y fi ; Journal Server Layer
Post Office 1 Post Office 2 Post Office n
(Single- and multi-counter position offices)
Fig. 2 - The Two Layers of Riposte Architecture
Correspondence Server Layer
4.3.2.5,3 The major functions of the correspondence layer are :
«Distribution of payment data (files) to the relevant post offices to allow card-
based payments to be made
* Capture of all transaction messages related to benefit payments, bill
payments, and other applications
* Replication of messages across other correspondence servers to support
back-up and recovery facilities
* Provision of broadcast facilities to support enquiries and other on-line
transactions
* Provision of software agents to provide transaction details to various client
systems
Journal Server Layer
4.3.2.5.4 The major functions of the local layer are :
* Presentation of transactions to counter staff in an intuitive fashion
* Support of a wide range of peripherals needed to enable electronic
transactions
¢ Capture of all transaction details to support reconciliation and audit
* Replication of transaction messages to all other office workstations to
support back-up and recovery
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.2.5.5
4.3.3
4.3.3.1
4.3.3.1
4.3.3.1.2
* Replication (on-line or trickle-feed) of transaction messages to the
correspondence server layer to support central functions and to provide
additional recovery facilities
Single workstations where journal messages are not replicated to other local
workstations are considered to be a special case. In this situation an alternative
strategy, such as replicating messages to a second hard disk, can be implemented
(this is similar to implementation on the ALPS project). Other recovery
strategies can also be considered in this special case.
Flexibiity
‘New Products
* Changes to Existing Products
‘Supports Business DevelopmentI
‘Objectives
“Automatic Recovery
+Relisbility
L _t
I
Visual Basic
‘Wide Availabilty of kills
‘Availability of Inerface
Components from Riposte
+Wide Availabilty of PC
Fig. 3 - The Benefits of using Riposte as part of POCL Strategic Infrastructure
GENERIC APPROACH
INTRODUCTION TO PATHWAYS PROPOSAL FOR A GENERIC APPROACH
Pathway supports POCL’s objective of realising all of the counter applications
through the use of generic transactions. Riposte is based on a generic
transaction concept. All transactions fall into the categories of ‘in-payment’ or
‘out-payment’. Riposte also supports ‘transactions’ where there is no monetary
value involved. This could be a query on an account or the posting of interest
to a savings account book or a request from a benefit customer to change their
nominated post office.
All transactions are implemented using counter applications and Pathway is
taking account of POCL’s desire to use applications that are currently in
existence.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 7 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.3.1.3
4.3.3.1.5
Supporting these two objectives, Pathway proposes a development of POCL’s
‘Generic’ model. This development is primarily concerned with the
implementation of applications on the counter. Pathway proposes grouping
applications into generic types. Generic types of transactions are transactions
that are logically similar. For example, all bill payment transactions are similar
and hence it is easier to implement a generic bill payment application.
‘Generic applications’ are listed below with a statement of their current status :
Generic Applications
Status
Principal Functions
Benefit Payment
Currently in use for
magnetic stripe card-
based payments
Positive Authorisation
Stop Application
Emergency Payments
Household Budgeting
Transcash (in-payment
and out-payments)
Currently in use for
magnetic stripe card-
based bill payments,
OCR-based bill
payments and bar-coded
bill payments, cheque
cashing and postal order
cashing
Supports a wide variety of
bill formats and
multiple/mixed payment
types
Savings Account
Currently in use for
book-based Savings
Account
On-line account look-up
Interest Posting
Electronic Funds Transfer
Investment Products
Currently in use for
Savings Bonds, Savings
Certificates and
Instalment Savings
products
Includes a sales aid to assist
counter staff to provide
information
EPOS
Prototype available now.
Delivery scheduled Q1
1996
Postal Applications
Delivery scheduled Q1
1996
Stock
Delivery scheduled Q2
1996
Proposed groupings are mapped against transactions in the following table. (In
this instance Transcash is defined as any in-payment or out-payment supported
by a voucher.) Exact groupings will be agreed with POCL.
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE Page: 8 of 44
Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
Logical grouping of transactions
Groupings
Transactions Benefit I Transcash I Savings I Investment I Postal I EPOS
Payment. Account I Products I Service &
Stock
Benefit Payment LW,
_Issuc i
Change of address
BT
ill payments
sh cheque
Compensation Fee
arcel
Deposit
Franking machine
. Certificates...
INew account _
Packets/parcels
“Withdrawal v
4.3.3.2 DEVELOPMENT OF THE POCL GENERIC APPROACH
4.3.3.2.1 Having established that the transaction should be grouped logically into similar
types, Pathway proposes to create generic parameter-driven modules for each
generic transaction type. These modules will be based on applications already in
use.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 9 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.3.2.2
4.3.3.3
4.3.3.3.1
4.3.3.3.2
4.3.3.3.3
4.3.3.3.4
The Riposte architecture proposed by Pathway has, in itself, a high degree of
generic functionality. Every transaction developed will use the Riposte
environment and will therefore benefit from all of the audit, security, reliability
and recoverability features inherent in the Riposte architecture.
ADVANTAGES OF THE EVOLVED POCL GENERIC APPROACH
Pathway supports the generic approach for the following business reasons :
¢ Easier to navigate manually through the transactions
* Easier and less costly to develop when dealing with transactions of a similar
nature
¢ Easier to implement specific interface requirements for transactions of a
similar nature
* Simpler construction of parameter files for similar transactions
¢ Faster roll-out of new applications is enabled by the distribution of new
parameter files. This can be done by using the Riposte architecture
¢ Lower start-up costs than with a total ‘Generic’ approach
* Lower risk is involved because it is based on existing production applications
already in use
Some of these advantages are very important in making the applications
acceptable to counter staff. Two of these importance features are explored
further :
Manual Navigation
Using the logical grouping approach facilitates navigation through the
applications by the counter staff in the event that manual navigation is required.
The Riposte environment is normally driven by the occurrence of external
events. To activate a particular transaction the counter staff swipe a magnetic
card, read a smart card, scan a bar code or read an OCR line. This external
event automatically navigates the counter staff to the relevant application and
initiates the printing of a receipt, or carries out other relevant actions. During
normal operation, counter staff need little information about how to navigate
through applications.
Our proposal to group similar transactions into logical groupings is important
where the external event fails to navigate the counter staff automatically to the
relevant application. (Such a failure could be due to card damage, failure to read
the OCR line because it is smudged or creased, or failure of the counter-top
peripheral itself.) In this scenario the counter staff can navigate to the relevant
transaction screen by using the keyboard or touch screen depending on
hardware chosen. The transactions are then presented in order of likely
occurrence, and the counter staff select the application and key in the card
number or details as appropriate.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 10 of 44
OJEC Notice 94/S 165-5893 7/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4,3.3.3.5
4,3.3.3.6
4,3.3.3.7
4.3.3.3.8
4.3.3.3.9
4.3.3.3.10
Consistent User Interface
In addition to the proposed logical grouping of transactions, Pathway proposes
logically consistent user interfaces that vary depending upon the transaction
involved. This philosophy is explored further in the description of Pathway’s
development approach. In particular, all transactions will have a similar
consistent and recognisable interface. The development ensures that the
interface is appropriate to the transaction being executed. Some examples of
this approach are described below.
During the benefit payment process the counter staff make (for a normal
positively authorised transaction) only one keystroke (or one touch on the touch
screen) to complete the transaction.
A normal, positively authorised transaction follows this pattern :
1. The magnetic card is swiped.
2. The stop list of cards and payments is checked; payment details are
retrieved; a receipt prints.
3. The counter clerk confirms payment on the screen.
The only interactions the counter staff have with the system are to swipe the
card and confirm (or not) the payment. (The counter staff will also carry out
other validation checks such as signature verification - this is not an interaction
with the system.) A very specific and simple interface is required. This simple
interface supports the desire to process counter transactions as quickly as
possible.
In contrast, for a withdrawal from a savings account, the counter staff
electronically read or key in the account number. The book balance is
confirmed and the counter staff key in the withdrawal amount. In this scenario
there is greater interaction with the system, and an appropriate interface is
needed.
In the case of stamp sales, counter staff input the types and quantities of stamps
needed. In the case of a postal service application, the choices offered by POCL
and the cross-selling of other services needs to be supported by the interface.
These other postal services include :
* Guaranteed delivery
¢ Air/land
* Registered
* Insured
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 11 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTU!
4.3.3.3.11
4,3.3.3,12
4.3.3.4
4.3.3.4.1
4.3.3.4.2
4.3.3.4.3
4,3.3.4.4
Again, there is a significant difference in the level of interaction needed in
delivering this customer service from that in a straight in-payment. Similar
considerations need to be taken into account where counter staff are involved in
the sale of investment products and the system must support and guide them
through delivery of customer service.
In light of the above, Pathway wish to confirm that the generic transaction
approach is valid but that its deployment will be different to that proposed by
POCL in the SSR. This difference is significant but reflects the true nature of
POCL’s business. POCL is not just a retailer dealing with off-the-shelf products.
POCL is also a provider of services and the infrastructure must enable the
delivery of customer service, while supporting POCL’s business development
objectives.
BILL PAYMENTS
This example of Pathway’s generic approach is based upon the bill payment
module used at An Post in Ireland. There is no apparent difference in
functionality compared to that required in the UK. It conforms to the proposed
functional generic design and is in use today, satisfying the POCL goal of re-
using proven applications.
The complete bill payment process is driven by parameters. This enables new
bill types to be added for existing or new clients, without _re-programming,
which reduces the risk of bugs. In addition, the parameter file can be distributed
to local post offices using the Riposte architecture, thus eliminating a software
distribution problem.
Each bill is defined by an entry in the parameter file. The format of this entry is
A =B,C,D, E, F, [G], [H], [1], [J], -.-... [U]
Parameters B to F must always be present. The other parameters are used to
describe more fully the details of the bill payment transaction. A simple bill
payment can thus be described as follows :
33109=,Standard,In,Transcash,Both,
Full +Mod10,8,8,10000000,89999999,7.70,88.00,,445,,CABLE.bmp,
&CableCompany
The parameters are used to describe the nature of the bill payment being
automated and they include :
* The transaction code
* The text describing the transaction
* The MSR/OCR or bar code format
* The transaction type (in-payment or out-payment)
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 12 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.3.4.5
4.3.3.5
4.3.3.5.1
4.3.3.5.2
4.3.3.6
4.3.3.6.1
4.3.3,6.2
4.3.3.6.3
¢ The application name to be recorded in the journal entry
* The check digit calculation
¢ Maximum/minimum length of acceptable account number
* Minimum amount payable on bill
¢ Maximum amount accepted without warning
¢ Whether personal details (name and address, etc.) must be captured
¢ Whether there is an additional fee to be collected
¢ Whether a company logo for the client is to be displayed on the screen during
the transaction
The use of the generic approach as described in the above section will have a
positive impact on the timescale as it will to a large extent be using or will be
based on applications already in use.
ECCO+ REPLACEMENT
As with Bill Payments, an application built to the generic design standard
already exists. The functional fit will be less than that of Bill Payments, but
should be better than 50% as a minimum, and could be as high as 70%.
More work is required to qualify the work required to meet POCL’s
requirements, but the elapse time to completion is estimated at not more than
eight weeks.
ENHANCED ESNS BENEFIT AGENCY SYSTEM
Pathway has a clear view as to how the Electronic Stop Notification System
(ESNS) as implemented for ALPS could be strengthened ahead of positive
authorisation being available, which will depend on the availability of CAPS, At
present the ESNS system is based on negative authorisation. Possible
strengthening of the ESNS system which can be agreed with BA and POCL will
include :
¢ Capture of payment book details including number of payable orders at point
of issue
* Verification of encashments against the database of payment books issued
* Management of foreign payments electronically with on-line verification of
all books not issued at office of encashment
The above proposals are based on upgrading the existing ESNS business
processes and software infrastructure. As an alternative, in advance of the
availability of CAPS, Pathway will consider taking payment information from
BA to enable limited function card-based payments. This could involve the
interception of the electronic print stream and the creation of payment records
for distribution to the post offices.
Pathway through ICL (the contractor on the ALPS project) is well positioned to
implement any or all of the above enhancements to the ESNS.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 13 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4,3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.3.6.4
4.3.4
4.3.4.1
4.3.4.1.1
4.3.4.1,2
4.3.4.2
4.3.4.2.1
Pathway is also investigating the possibilities of reading the counterfoil plain
text electronically and therefore allowing full reconciliation without upgrading
the paper-based system.
TRANSACTION MANAGEMENT SYSTEM
INTRODUCTION TO TMS
The key objectives of Pathway’s proposed architecture for supporting POCL are
* To provide a stable and flexible environment that facilitates the growth in
volume of existing transaction types and the introduction of new transactions
with a minimum of change
* To provide a secure environment that is resistant to fraud
¢ To remove operational costs and add operational integrity
* To support full audit and reconciliation of all transactions
¢ To provide an environment that facilitates optimum performance of staff,
network and equipment
¢ To support the sharing of functionality among application subsystems
* To support a speedy response to business needs
¢ To provide an environment requiring minimum maintenance
Pathway is using the Riposte system from An Post/Escher as an integrated
component of the solution because it provides a high degree of support for the
above objectives. The transaction management system has a functional objective
to take the transaction from the counter system and convey it to the designated
client system in a secure and auditable manner. The facilities of Riposte will
enable this functionality and in addition will enable POCL to provide additional
value to clients while satisfying its own internal needs.
INTRODUCTION TO RIPOSTE
Riposte provides a framework to allow for the easy development and
implementation of complex financial transactions. Riposte provides an
environment that ensures every transaction is implemented in a secure,
auditable, reversible and, when required, recoverable manner. Because of its
unique design, Riposte can handle every new transaction in the same consistent
manner, regardless of its complexity. By using the Riposte framework POCL
can guarantee that every transaction embodies the same high level of security
and financial integrity. A graphical representation of the Riposte components is
shown in Fig.4.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 14 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
> Desktop
ie D>» Facilities
/ Controls 2
Ye, Security
TEE
/ Encryption > Server
J Aathenticaion
Journal
Server
Disrbution
/ BACKUP Correspondence
/ Synchronisation/Communication one
Central Journalising
Backup/Recovery
Communications
Fig. 4 - Overview of Riposte Components
43.4.3 RIPOSTE - DESKTOP
4.3.4.3.1 The Riposte Desktop is a very important keystone in the transaction
development environment. The Riposte Desktop is an application development
standard. Using the Desktop the customer application has access to state-of-the-
art interface controls. These controls enable the application developers to
provide a very intuitive application which is consistent across all transactions.
The Desktop also provides for rapid application prototyping, which encourages
a more interactive application design methodology. It provides users with an
early view of the application, ensuring buy-in at an early stage and therefore
helping to achieve one of our major goals - user acceptance.
4.3.4.3.2 Desktop development aids and features include :
* Context-sensitive help balloons
* Elevator control button menus
* On-screen keyboard
* Action lists
* Desktop buttons
* Overlaid image labels
4.3.4.3.3 Desktop provides a suite of software agents for device management. These
facilitate the integration of various peripheral devices into the counter
applications. These software agents free the application developer from tedious
system development. Typically transactions include the use of magnetic swipe
readers (MSRs), optical character recognition (OCR), bar code readers, magnetic
ink character recognition (MICR), smart card readers and printers.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 15 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.4.4
4.3.4.4.1
4.3.4.5
43.4.5.1
4.3.4.5,2
4.3.4.5,3
4.3,4.5.4
RIPOSTE - SECURITY AND INTEGRITY
As required by any financial transaction environment, Riposte provides security
at many levels within the application. Riposte’s security server facilities provide
security and integrity normally associated with transaction environments,
including :
¢ User authorisation and password security
* Access control
¢ Digital signature
* Encryption of data, as required
¢ Integrity, including 32 bit Cyclic Redundancy Checking (CRC)
¢ Authentication to ensure that distributed files have not been tampered with
JOURNAL SERVER
The journal server is a critical component of the Riposte software. The journal
server manages the journaling, data distribution and data replication functions at
a local level within a post office. In the situation of a single-counter office and
where a workstation is designated as the communications workstation (normally
position 1 in the LAN is designated as the communications workstation), then
the journal server is also responsible for managing communications with the
central correspondence servers and replicating messages to the correspondence
server.
The journal server also provides a set of independent functions for
administering data integrity, including the application of CRCs at a transaction
level. The journal server may operate in an environment where there is a
permanent on-line connection to a remote (central) location or in a situation
where only periodic dial-up facilities are provided. The journal server operates
in a transaction environment where there is one or more local workstations.
This workgroup represents a typical front-office transaction configuration. The
journal server operates on all workstations in the workgroup, however a single
workstation handles the wide area network communication functions. Multiple
network protocols and topologies are supported. Pathway is proposing ISDN as
the preferred method for communication with post offices.
Each workstation in the journal server workgroup has information about its
neighbours, (see Fig.5) comprising the name and address of each of their nodes.
The communications workstation has information about a remote node, in other
words, the correspondence server.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 16 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
(PY 3 $
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
Correspondence Server 1
Name : CS1
Nodes Address
PO1 Post 1, ISDN
cs 2, LAN
#4 LAN
S <
Position 1
Position 2 Position 3
Nodes Address
PO1Post 2, LAN Nodes Address Nodes Address.
PO1Post 3, LAN PO1Post 1, LAN PO1Post 1, LAN
cs 1, ISDN PO1Post 3, LAN PO1Post 2, LAN
Fig. 5 - Overview of a Journal Server Workgroup
43.45,5 Using the node information, every message generated at one of the positions is
replicated to all the known nodes in the node list.
Attribute Grammar
4.3.4.5.6 Attribute grammar is the technique used for storing data within the Riposte
environment. In particular, each journal message is in attribute grammar format.
In attribute grammar both the description of the data item and its associated
value are stored in the data file. Using attribute grammar allows message
formats to be changed or new messages for new applications to be added
without modifying the applications already in use at the counter. The facility
allows software upgrades to be implemented on a rolling basis, and adequate
field testing on a small sample of offices in parallel with ongoing operation, if
desired.
4.3.4.5,7 The structure of journal messages generated by different applications can vary
greatly but the messages are processed in precisely the same manner. This
allows POCL to specify at an application level the information to be captured by
any particular transaction at the counter. Riposte will cater for virtually an
unlimited number of attributes.
Sample Journal Message Attribute Grammar
<Message: <Group:GROF3050><Node:POST1 > <Id:1> <Num:38210> <Date:23-Jun1995 >
<Time:08 :57:39> <User:ANNE> <Debit:6100> <Application:Postdraft> <TranDate:23-Jan-1995 >
<Data: <PaymentNumber:B9232765 > <NINO:5146317654> <RecipientName:JOHN LANDIS>
<TranType:Cashed><ReceiptsPrinted: 1 > <OcrData: <Date:3050 > <AcctNo:00029873952>
<Amount:6100><TranCode:98034> > <File:PAY00146.TXT >> <CRC:5395E7 10>>
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 17 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.4.5.8 Attribute grammar is also used to describe the data elements that make up other
information files, for example benefit payment files.
4.3.4.6 KEY FUNCTIONS PROVIDED BY JOURNAL SERVER
4.3.4.6.1 The functions provided by the journal server are described in the following
sections :
Audit Trail Of all Transactions
4.3.4.6.2 As each counter application performs a transaction, it informs the journal server
via the Windows DDE (Dynamic Data Exchange).
4.3.4.6.3 The transaction sent to the journal server is formatted as a single text string
called a journal message, but the content of each journal message varies
depending on the application and the transaction. The following is a typical
example message :
POST OFFICE ID
POSITION ID
TRANSACTION ID
DATE
TIME
USER
APPLICATION
TRANSACTION DETAILS 1
TRANSACTION DETAILS N
4.3.4.6.4 Transaction details for a typical out-payment can include :
¢ Payment ID : A unique payment number
* Debit amount : Amount paid
* National Insurance
Number
* Transaction type : Out-payment
¢ Transaction code : Specific benefit ID
* Receipt details : If one or more receipts were printed
« Keyed ID : If keying of the transaction took place
* Keyed Reason : The reason the transaction had to be keyed
4.3.4.6.5 The journal message is output to the local workstation journal file, and
replicated to all workstations in the journal workgroup. The message
replication concept is illustrated in the Fig. 6 below.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 18 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
r
os
eN
)
Ne rk
Newest.)
a ns
1
Leg SOPS
Step 1 Card is swiped and
‘transaction details are a “a
retrieved. Seep i e
Step 2. Customer is paid. ky
Step 3 Payment transaction details are
written to local journal message
store.
Step 4 Payment transaction details are
replicated to other local workstations
message stores.
Step 5 Payment transaction dewails are replicated
10 Correspondence Server when
communications are initiated.
Fig. 6 - Message Replication
Journal Entries and User Security Validation
4.3.4.6.6 A cyclic redundancy check (CRC) is applied to all journal entries. On receipt of
a request for an entry, the journal server validates the CRC on the entry before
returning it to the application.
4.3.4.6.7 All user authorisation functions are logged to the journal file including logon,
logoff, add user, modify user and delete user. Password management and
password expiry are also delivered by the journal.
User Authorisation
4.3.4.6.8 The Desktop provides facilities to maintain and control user access to the
system. Multiple user types are supported and access to different functions can
be restricted by these user types. Complete control over password changes (for
example, minimum password lengths, preventing re-use of old passwords) and
automatic password expiry are also provided. Users are informed prior to
password expiry. The Desktop also provides password encryption.
Logon processing
4.3.4.6.9 The Desktop prevents a user from simultaneously logging on to multiple
workstations within the same workgroup whenever it can positively confirm
that the user is logged on to another workstation.
4.3.4.6.10 I Whenever an asynchronous event (an asynchronous event includes the swipe of
a magnetic card or the reading of a bar code) occurs while no user is logged on,
the Riposte Desktop automatically prompts for a user logon.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 19 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.4.6.11
4.3.4.6.12
4.3.4.6.13
4.3.4.6.14
4.3.4.6.15
4.3.4.6.16
4.3.4.6.17
Synchronise all Workstations on the LAN
On receipt of a journal message from an application running on the current
workstation, the journal server replicates that transaction, via Windows DDE, to
the journal servers running on the other workstations on the office LAN. On
receipt of the journal message, each workstation journal server writes it to its
own local journal file.
At regular intervals each workstation in a journal server workgroup sends a state
message to all other workstations in the workgroup. The state message contains
information about the workstation’s current state and the last known state of
each of the other workstations. Specifically the state information refers to the
last journal message sequence number.
On receipt of the state message, the individual workstations check the state
information. If the last known journal message sequence number indicates that
journal entries are missing from one or more of the other workstations, then the
workstation requests them. Using this facility all workstation journals on the
LAN remain synchronised.
Synchronise the Office Workgroup and the Correspondence Server
Every workstation in a journal server workgroup (in other words, on the same
LAN) knows the ID and address of all other workstations in the workgroup.
This is the way the LAN synchronisation described above is carried out.
In each office one workstation is nominated the communications workstation.
This workstation knows about all local workstations and in addition it has node
and address information about a correspondence server. The result of this is
that all transactions performed at the office, on all workstations, are forwarded
to the correspondence server. In an on-line environment this replication takes
place continuously. In the situation where offices are off-line, the replication to
the correspondence server takes place whenever communications are
established.
Synchronisation of the Date and Time on all Workstations
The journal server provides a function that synchronises the date and time on
each PC in the office with the date and time on the correspondence server.
File Distribution
File distribution on the journal server supports the distribution of files from the
correspondence server and the replication of them across all workstations in the
LAN. Typically these files contain either payment information data or
information controlling the operation of the counter applications, such as
parameter files,
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 20 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.4.6.18
4.3.4.6.19
4.3.4.6.20
4.3.4.6.21
4.3.4.6.22
4.3.4.6.23
To distribute a payment file from a central correspondence server to an office,
the system completes the following steps :
1. The correspondence server creates a CREATE file journal message, places it
in the journal file, and places the file in a data directory.
2. Upon synchronisation, the post office communications workstation
recognises a state mismatch with the correspondence server and updates its
local journal with the journal messages from the correspondence server.
3. Upon receipt of the CREATE file journal message, the workstation checks for
existence of the file locally. If it does not exist it requests and downloads the
file.
4. In the same way, all other workstations in the journal server workgroup
detect the CREATE file journal message and replicate the payment file from
the communications workstation.
File Deletion
In a similar manner to file creation, when a file is to be deleted, a DELETE entry
is logged in the journal and acted on by each of the workstation journal servers.
Recovery
In the situation where there is a state difference between journals on the local
workgroup LAN and the correspondence server journal, the synchronisation
process takes place as described above. An extreme case of this situation is
where the journal needs to be completely restored. Such a situation may arise in
the unlikely event of a hard disk failure or the destruction or theft of the
workstation.
In this situation the faulty workstation is typically replaced by one with the
operating system and application software already installed. The only further
information that needs to be added is the personality information relating to the
workstation. This includes identification information and information about
other local workstations and correspondence servers. The journal file will
however be absent. In addition to recovering. the journal messages from all
other workstations it must recover the messages that originated from the failed
workstation.
The recovery is handled using the synchronisation protocol, with the exception
that no new messages can be generated by the new or replaced workstation until
all the messages originated by its predecessor are fully recovered. It is not
necessary to recover all messages originated at other workstations before
commencing operations, as these will be recovered as part of the normal
synchronisation process.
No central or local human intervention is required to complete this recovery
process. As well as recovering the journal file, other information such as
payment files is also recovered.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 21 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4,3.4.6.24
4.3.4.6.25
4.3.4.6.26
4.3.4.6.27
A special case of recovery is needed for catastrophic failure of a workstation in a
single-counter office. If dual hard disks are not supported (as in the ALPS
project), when the workstation is replaced, the journal server detects the absence
of the journal file and recovers the complete journal from the correspondence
server.
In the scenario where all workstations in a multi-counter office suffer
catastrophic failure such as fire, flood or theft and need to recover, the
communications workstation recovers from the correspondence server and the
other workstations recover from the communications workstation in parallel.
Provide on-line Services from Post Offices to Central Systems
A journal message is generated by the application requiring the on-line service.
This message is replicated over the office workgroup. When received by the
communications workstation, the message is recognised as ‘on-line’, the
communications channel is opened and the message is again replicated to the
correspondence server. On arrival at the correspondence server, a software
agent detects the message and sends it for processing to the appropriate system.
The response is returned to the correspondence server and is replicated back to
the office, to the waiting application. On-line services include lookup of
balance for savings account, lookup of interest on savings account, check on
foreign encashments and other queries. At An Post in Ireland an on-line query
or transaction completes in less than two seconds in 95% of cases.
Archiving
The journal server currently provides local archiving facilities for the journal
file. At present the journal archive is performed at file level. The archive period
is configured as a parameter within Riposte. Archive files are also managed by
Riposte (for example archive files can be automatically discarded after a
designated period of time). A more fundamental archiving strategy will be
implemented based on the concepts of ‘incept and mortality’ at the journal
message level. Incept allows a message to remain dormant until the incept date
has been reached. The journal will be aware of such messages before the incept
date but this information will not be available to the counter applications.
Mortality allows messages to exist and be available to applications until they die
or expire. Using these concepts messages will be archived dynamically.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 22 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4,3.4.6.28
4.3.4.6.29
4.3.4.6.30
4.3.4.6.31
4.3.4.6.32
4.3.4.7
4.3.4.7.1
Transactioning
Multiple journal messages may be committed to the local message store as a
single atomic operation. In the event of a system failure, the journal server
ensures that either all of the messages have been stored, or that none of the
messages has been stored.
Attribute Indexes
Due to the nature of attribute grammar, Riposte allows indexes to be built by the
application, which support retrieval by a particular attribute or combination of
attributes.
An attribute index is a permanent index that is dynamically maintained to
improve the performance of queries against the message store. Attribute indexes
may be created on any message attribute, and are added or removed dynamically
as required by the application.
Retrieval Indexes
A retrieval index is used to allow the retrieval of a selected set of journal
messages in a specified sort order. Compound keys are supported and an
arbitrary number of attributes are allowed. Retrieval indexes provide a
consistent snapshot of the message store so that reporting can be performed
while the message store is still being updated without danger of inconsistency in
totalling or ordering. Retrieval indexes may be created dynamically on demand,
as required. Retrieval indexes can be built as either hash tables or b-tree
indexes, depending on the type of access required.
Operational Integrity
Each message is automatically appended with a 32-bit CRC (Cyclic Redundancy
Check) attribute. Whenever a message is received from another workstation or
retrieved from the local message store, the CRC attribute is validated to ensure
that the message has not been damaged or modified. CRCs are also applied to
all index pages to ensure the integrity of all attribute indexes.
CORRESPONDENCE SERVER
As described in Section 4.3.4.6.5, the journal server provides messaging support
and replication at the office workgroup level. The correspondence server is a
version of the journal server, providing centralised network facilities and
connectivity to other client support systems. The correspondence server
participates in multiple workgroups simultaneously by communicating with the
journal servers in each of the multiple workgroups. The messaging model and
communications protocol between a correspondence server and a journal server
is identical to that between two journal servers in the same workgroup (even
though the network topology may be different).
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 23 of 44
OJEC Notice 94/S 165-58937/EN_ Date: 08/06/95
FUJ00098232
FUJ00098232
iy
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4,3.4.7.2
4.3.4.7.3
4.3.4.7.4
43.4.7.5
The consequence of this consistent messaging protocol is that all of the
synchronisation and recovery facilities provided by the journal server are
provided by the correspondence server to its workgroup members. The most
obvious benefit of this is that a single-station office can be recovered from the
correspondence server in the same way that a workstation can recover from its
peers in a multi-counter office.
Replicated Correspondence Servers
The same messaging protocol that is used to provide replicated messaging
among members of a workgroup can be used to replicate messages among a
group of correspondence servers. Operating multiple replicated correspondence
servers ensures the resilience and recoverability of the central network services.
Optimised Correspondence Server Recovery
Where there are multiple correspondence servers (more than two), then a
strategy for replicating transactions can be implemented that allows a
correspondence server to recover without unduly loading other correspondence
servers in the same group. This is achieved by replicating journal messages for
each correspondence server selectively across each of the servers in the group.
This strategy is represented in Fig.7.
Correspondence Server Layer
Other ~t H % Other
Correspondence I
Servers Servers
Replicared Messages Replicared Messages Replicated Messages
For Post Offices For Post Offices for Post Offices
1001-2000 and 1501-2000 and 1001-1500 and
2001-2500 etc. 3001-4000 etc. 2001-3000 ete.
Fig. 7 - Replicated Transactions
Data Distribution
In our proposed architecture, payment information is made available from PMS,
it is then digitally signed and replicated to the target post office by use of the
CREATE file journal messages.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 24 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
Correspondence
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.4.7.6
4.3.4.7.7
4.3.4.8
4.3.4.8.1
4.3.4.8.2
4,3.4.8.2
Archiving
Archiving at the correspondence server level is totally independent from the
archiving strategy adopted at the counter level. In practice Pathway in
conjunction with POCL may decide not to archive at the counter level but
implement all archiving at the correspondence server level. The principal need
for archiving is to support after-the-fact fraud investigations and intensive off-
line analysis for management information. Pathway is investigating several
options for archiving which will probably include the use of write-only optical
disks and associated juke-box library technology.
Memo Facilities
Using the correspondence server, memos can be delivered to individuals or
selected post offices. A memo is created using a simple text editor. The memo
application then places a CREATE file message in the correspondence server
journal. When a communications session is established with the relevant office,
the memo will be available to the memo application at the counter.
OPERATIONAL INTEGRITY
For a system to be truly fault-tolerant in a real-world environment, it is not
sufficient just to be able to recover from system crashes and network failures. It
is also necessary to be able to safeguard the operational integrity of the system
from the wide range of everyday errors that occur in any production system,
many of which are not caused by hardware failures. The operational integrity of
a system may be violated by a modification to the application data, system
configuration or the application itself. Such modifications may be due to
hardware failures, but are more commonly the result of faults in the application
or system software or both, or as a result of operator error (unintentional or
malicious). The Riposte messaging and data distribution facilities provide a
number of features designed to preserve the operational integrity of a system.
Cyclic Redundancy Checks
The primary tool used by Riposte for detecting data corruption is the CRC
(Cyclic Redundancy Check). A CRC algorithm translates a string of data into a
binary integer. (Riposte uses a 32-bit CRC algorithm supplied and licensed by
PK Ware Inc.) By computing the CRC of a data string (for example, a message),
the CRC can later be used to detect whether the data string has been modified.
This is achieved by re-computing the CRC and comparing it to the initial value.
If the re-computed CRC differs from the original CRC, then the system
considers the data string to have been modified in some fashion. With a 32-bit
CRC the probability of not detecting a random modification is less than 1 in
4,000,000,000.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 25 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.4.8.3
4.3.4.8.4
4.3.4.8.5
4.3.4.9
4.3.4.9.1
The Riposte messaging system automatically applies a CRC to every message
when it is originated. This CRC is then validated any time the message is
accessed, whether the message is retrieved from the local message store or the
message is received over the network. If a CRC validation fails for a message
received over the network, the message is discarded and automatically re-
requested. If a CRC validation fails for a message retrieved from the local
message store, then the local message store is considered to have been
compromised. In this situation the local message store is invalidated and
recovery is initiated from another member of the workgroup.
In addition to the CRC validations performed on messages and distributed files,
CRCs are also used to validate the integrity of various internal Riposte data
structures, such as attribute indexes and internal message caches. In the event
that a CRC validation fails on an internal data structure, the data structure is
invalidated and re-constructed automatically.
Digital Signatures
While CRCs provide a simple and efficient way to detect most types of data
corruption, they are not sufficient to ensure that critical data is protected from a
malicious adversary with access to high-speed computing facilities. In order to
protect vital data files from any type of tampering, Riposte includes a security
subsystem that provides ‘public key’ digital signature facilities. Critical data files
(such as benefit payment files) may be digitally signed by their originator. These
digital signatures are then authenticated whenever the signed data file is
distributed or access is requested by the application. With the ability to generate
pairs of keys of any desired length, the system designer can select the level of
protection desired for different components of the system. If a digital signature
fails authentication, the data file in question is invalidated and automatically
recovered from another member of the workgroup. In addition, an audit
message containing details of the authentication failure is logged and transmitted
to the correspondence server for review by the system security personnel.
RIPOSTE - UTILITIES
Riposte provides a set of utilities that operate independently of all customer
applications. These utilities enable a highly available and fault-tolerant
application to be developed, tested and operated. A selection of these utilities is
described below :
(a) Log Spy : Provides a dynamic display of all journal log entries as they are
created.
(b) Message Spy : Provides a display of all messages generated by multiple
workgroups of journal servers with suitable filtering, as defined by the user.
(c) Journal Client : A test suite to simulate the activity of a journal server. This
is useful for testing network and correspondence server performance.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 26 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.4.10
4.3.4.10.1
4.3.4.10.2
(d) Speedometer : Provides a real time display of message processing by the
journal or correspondence servers. This provides useful information for
performance enhancement and can be used with the journal client to assess
the impact on performance of new applications.
VALUE ADDED PROCESSING AND INTERFACE TO CLIENT SYSTEMS
One of the key functional roles of the correspondence server is to provide an
interface to different client systems. To carry out these functions ‘software
agents’ are used to interface to the different client systems. Upon startup each
of the software agents registers with the correspondence server informing it of
the application and type(s) of transaction(s) that it is interested in. One
variation of the software agent is responsible for real time on-line transactions
discussed earlier. This software agent type is presented graphically in Fig. 8.
1, Message replicated 7. Message replicated
from local post office to local post office
j + 6 Nesp rein
to correspondence server.
ai
I Conrespondence Server! o I Software Agent!
2, Message replicated 3. Message replicated
to journal message store, to sofeware agent 4 Cnery passed to
4
I 5. Response returned to
i software agent
_J
I On-line System I
Fig. 8 - Software Agent for On-line Query
In addition to the on-line type of transaction, Pathway will collect client
transactions using other software agents as shown in Fig. 9. Once a client
transaction arrives at the correspondence server it is written to the journal
message store in the normal fashion and replicated to other correspondence
servers as required. The correspondence server can also pass the journal
message to any software agent that has registered its interest in this type of
transaction; the software agent can then pass the transaction to the client system
in real time. This retrieval of transactions from the correspondence server can
also take place on a periodic basis in batches, or in batches as the result of the
correspondence server receiving an end-of-day marker from a post office.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 27 of 44
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
1. Message replicated
from local post office
I Correspondence Server wa i Software Agent I
»
. Message replicated
to software agent 4, Message passed to
OR client system
2, Message replicated
to journal message store
»
. Messages retrieved in
batches by software agent
Client System
Fig. 9 - Software Agent for Collecting Client Transactions
4.3.4.10.3 A software agent for processing on-line transactions together with a system for
aggregating client transactions in batches is already in use at An Post. Pathway
will further develop these software agents to develop a set of generic software
agents for collecting transactions from the correspondence server for clients and
handling the different client system interactions required. These software agents
have been divided into the following generic categories :
This Software Agent : Has this Function :
File Distribution Acquisition of data from client systems and
creation of a file for distribution through
the Riposte architecture
Client Processing Collection of transactions for client systems,
formatting transactions in format required
and passing of this information back to the
client host
On-line Providing on-line queries from the strategic
infrastructure to the client system or
providing queries from the client system to
the strategic infrastructure
4.3.4.10.4 Prior to dispatch of files to the client system the infrastructure will allow POCL
to provide additional processing of the transactions to add value to clients.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 28 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
= .
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.4.11 INTERFACE TO POCL SYSTEMS
4.3.4.11.1 I POCL has indicated that separate projects are addressing the areas of transaction
information processing, distribution and financial administration. The type of
interface required by these systems will be determined by the processing
constraints on these systems. Given that information can be passed to clients
using any of the above software agents, Pathway will be capable of addressing
POCL’s requirements.
4.3.4.12 END TO END BILL PAYMENT SERVICE
4.3.4.12.1 As an example of the Transaction Management Service, we examine and present
a standard bill payment process below :
Step I Action By _I Standard Bill Payment Comment
1 Customer I Presents Bill The bill is encoded with the account
number/amount/company identifier
2 Counter Scans document If document cannot be scanned, a key
I Staff entry facility is also available.
Similarly if the amount is not on the
document counter staff can key in the
amount
3 SYSTEM. Accepts information The system validates the account
format and check digit, the size of
(The system also calculates fees if I account number upper and lower
appropriate for the transaction.) I bounds on the account number and
the minimum/maximum amount
payable
4 SYSTEM Displays information from scan I Including any fees calculated if
on screen for the counter staff appropriate
5 Counter Accepts payment The system will accept payment
staff amounts different from the scanned
(The system can accept partial amount and multiple payment types.
payment if required) For example the system accepts both
cash and cheque for the same bill
payment
7 SYSTEM Prints receipt The system will also endorse the
cheque if appropriate
8 SYSTEM Creates journal entry The journal message contains the
complete transaction details. The
message is replicated to the other
counter workstations in the office.
This information will be used for
teller and office balancing
9 SYSTEM Transmits transaction to central I Journal message is replicated to the
correspondence server correspondence server as soon as
connection is established
10 END The counter component of the
strategic infrastructure has now
completed its task
4.3.4.12.2 An example screen from the Bill Payments application running in An Post is
shown in Fig. 10 on the next page.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 29 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 30 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4,3.4.12.3 The transaction is now handled by the correspondence server. The following
table presents the further processing of the transaction :
Step I Action By I Standard Bill Payment Comment
1 TMS Collates all information for one
or more POCL clients from all
correspondence servers
12 TMS Prepares data as appropriate Company format may be created at
! this stage through Value Added
Processing or POCL may decide to
undertake this task
13 TMS Makes data ready for Data for client will need to be
collection/transmission to POCL I individual transactions, however
and/or POCL client POCL may only require transaction
summaries broken down by client by
individual post office for
reconciliation
14 TMS creates correspondence server
journal entry recording status of
transactions processed
4,3.4.12.4 A sample bill payment transaction record is provided below, showing the
attributes and transaction details :
<Message: <Group:GROF3050><Node:POST2><Id:2> <Num:36701> <Date:23-Jan-1995 >
<Time: 22> <User:DENISE> <Credit:1753><Application:Transcash> <Data:<TranType:BillPay>
<Tendered:1753 ><Payment Method:01 > <OcrData:<Date:0195 > <AcctNo:00270267577>
<Amount:1753><TranCode:05103> > <Full:Yes> <All Payment Methods:<Description:Cash>
<Payment Method:<Type:01> <Amount:1753>>>><CRC:D17F8433>>
4.3.5 COUNTER INTERFACE
4.3.5.1 INTRODUCTION
4.3.5.1.1 Another of the key features of Pathway’s solution is the counter interface, which
enables POCL staff to deliver the highest level of customer service. The
interface is proven and implemented in the ALPS project and is also
implemented at An Post in Ireland. The counter interface is based on the
Riposte system, which was developed by An Post/Escher.
4.3.5.1.2 The complete interface is event-driven. The act of swiping a magnetic card or
reading either a bar code or a line of OCR, automatically navigates the counter
staff to the required menu screen and kicks off an appropriate action, such as
printing a receipt.
4.3.5.1.3 In addition to the normal event-driven process, the user may navigate through
the applications using the keyboard or touchscreen. It may be necessary to do
this in the event of a card-read failure or inability to read the appropriate bar
code or OCR text, or both.
4.3.5.1.4 An example of the Encashment screen from ESNS is shown in Fig. 11 on the
next page.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 31 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 32 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ay
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.5.2 BUSINESS NEEDS
4.3.5.2.1 The counter interface is designed to allow the wide variety of staff encountered
in post offices to become familiar with all electronic transactions very quickly.
The intuitive nature of the interface will reduce costs (facilitating a rapid roll-
out) due to lower training requirements.
4.3.5.2.2 The principles of good interface design must be the foundation of application
design where the users of the system are principally non-technical and vary
greatly in age and previous computer experience. These principles include
* Adequate feedback
¢ Simple instructions
* Quick recovery from keying mistakes
¢ Event-driven
* Simple to navigate and discover
* Quick and invisible recovery from infrastructure failures
© Quality on-line help available as required
4.3.5.2.3 The principles are supported by the development approach (discussed in Section
4.3.5.5) and by the use of carefully chosen peripherals. Pathway is continually
examining the market for counter devices that will bring maximum benefit to
POCL while balancing the needs of cost, reliability, usability and at the same
time optimising the counter space.
4.3,5.2.4 Based on the principles of good graphical-user-interface design, Pathway’s
solution provides a consistent interface to all transactions. In summary, the
benefits of good interface design are :
* Easy roll-out due to lower training requirements
* Rapid introduction of new products and services, with zero or minimal re-
training
* Easy transfer of staff from reduced-product-set offices to offices with the full
range of products
4.3.5.2.5 The graphical nature of the interface supports the POCL critical success factor
of Universality.
4.3.5.2.6 An example of the on-line help facility currently in use in An Post is shown in
Fig. 12 on the next page.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 33 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 34 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.5.2.7
4,3.5.2.8
4.3.5.3
4.3.5,3.1
4.3.5.3.2
4.3.5.3.3
4.3.5.4
4.3.5.4.1
In addition, Pathway is able to demonstrate the substantial functions of the
initial BA/POCL programme (bill payment and benefit payment) in operation in
the An Post environment. While the Riposte architecture allows to develop and
implement any transactions they choose by using the Riposte application
program interface (API), where appropriate Pathway is proposing to use
applications or components of applications already in use. These components
are in use at :
¢ ALPS London area
¢ An Post, Ireland
Case studies for both of these projects are included in Annex 6.5 and 6.12.
Building on this experience means that the Pathway solution can be delivered to
the short time scale required by BA/POCL.
IMPLEMENTATION OF COUNTER INTERFACE - TECHNICAL
Riposte provides an end-to-end secure transaction environment. The function
of Riposte is to provide a secure and intuitive front end to transactions at the
counter level, in order to :
* Deliver payment information to the counter in a secure fashion
¢ Provide a high degree of reliability and recovery
* Provide a consistently high degree of auditability for all transactions
implemented in the Riposte architecture
* Provide balancing of automated transactions
In terms of the counter interface, Riposte provides a number of Desktop
modules that can be incorporated into the application design in order to provide
consistency.
The interface can be driven by a keyboard or by a touch screen. Touch screens
optimise the counter real estate and complement compact keyboards, instead of
full-size, conventional keyboards. Pathway is not proposing touch screens as
part of the base configuration but would like the opportunity to discuss the use
of touch screens further with POCL.
SOFTWARE ENVIRONMENT
The counter solution is currently implemented using the Windows for
Workgroups environment from Microsoft. This platform was chosen for its
wide usage and its wide availability of support skills. Riposte has been tésted on
Windows NT and Pathway is proposing the installation of Windows NT at the
local layer. As Windows NT is certified on the Intel platform to US Department
of Defence C2 security level this is a consideration in the choice of platform.
The appropriate releases of the Microsoft operating systems will be used for
implementation during the course of this project.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 35 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
Ss
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.5.4.2 By using the combined Intel and Microsoft product set, POCL will be able to
take advantage of new developments in software, hardware and peripherals.
Manufacturers invariably produce the first release of their products and software
drivers for this platform. In addition the skill set for development in this
environment is widely available and is being used as the platform for an ever-
increasing number of retail solutions.
4.3.5.4.3 The Intel and Microsoft combination is a living system of hardware and
software which has constantly developed since its first introduction in 1978.
Current Windows installations exceed 40 million. By 1998 the installed base of
Windows systems will exceed 80 million systems. This compares very
favourably with competing systems such as OS/2 which has significantly fewer
installed systems and hence support and releases of drivers for newer peripherals
can be a problem.
4.3.5.5 DEVELOPMENT ENVIRONMENT AND APPROACH
43.5.5.1 All counter applications are constructed using the Riposte API. The use of the
API gives all transactions the same high degree of security, reliability and
auditability. The API allows the application developer to concentrate on the
look and feel of the application, while Riposte takes care of all the audit-
recovery and security features of the transactions.
4.3.5.5.2 Visual Basic was chosen for the application development because of its highly
productive development and prototyping capability. In addition to the Desktop
controls provided by Riposte, there are extensive third-party interface
components available for Visual Basic. As needed Visual C/C++ is used to
create DLLs for use within the Visual Basic code (see Fig. 13).
Riposte Environment
ie I Riposte API
I Microsoft Visual Basic I
Riposte Desktop
/ Riposte Peripheral Support
I Third Party VBX Controls
Application Development Environment
Fig, 13 - Riposte Application Development Environment
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 36 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ie
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.5.5.3
4.3.5.5.4
4.3.5.5.5
4.3.5.5.6
4.3.5.5.7
4.3.6
4.3.6.1
Visual Basic combined with the Riposte Desktop facilities allows new
transactions to be prototyped and refined in conjunction with external clients.
The rapid prototyping facilities will facilitate new business development.
The application development approach is defined as ‘trust-based rapid
application development’. This approach varies significantly from traditional
development methodologies. In a traditional development environment the user
is charged with defining the requirements. This is a high-pressure task and the
risk of getting it wrong is significant. In response, the user asks for everything
to ensure that nothing, however spurious, is omitted. During the development
cycle the user is insistent that all the requirements are met and ‘blames’ the
developer for all problems. When an item is omitted from the requirements
definition the developer cites this as a reason for other delays. This is
development by conflict.
The trust-based approach requires a high-level statement of business
requirement from the user management group. This is followed by users
defining the required business rules. The designer takes both needs and
constructs a prototype. The prototype is constructed using a set of interface
standards that are appropriate to the functionality being developed. The user
then reviews the prototype with the developer and refines the business rules and
the user interface. Once the prototype has reached a stable state, application
development starts.
By making the developer and the user feel comfortable, this approach brings
considerable proven benefits to the resulting application. These advantages
include :
* More efficient code, due to a clearer understanding of the actual
requirements
* More useful design because the designer is not constrained by the user-
defining components of the system
* More user-acceptable system because the designer and the user both worked
on the interface
¢ Faster development because time is not wasted on spurious user needs
* Less fear of getting it wrong because the user can initiate change as part of the
prototype review
Application development using the Riposte environment supports the trust-
based approach because the Riposte infrastructure significantly reduces the
systems design component of application development, allowing the developer
to concentrate on the interface design.
OPERATIONAL SYSTEMS SUPPORT
The components of operational systems support that are required as part of the
procurement are Outlet Remuneration and Reporting and MIS.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 37 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
Be .
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.6.2
4.3.6.3
4.3.6.4
4.3.7
43.7.1
4.3.7.1.1
4.3.7.2
4.3.7.2.1
4.3,7.2.2
The Riposte architecture allows the Transaction Management Service to collect
transaction information at a very detailed level. Once collected through the
automated products at the counter the information is available for use by
different systems. In particular at the office for teller balancing, production of
the Cash Account and calculation of the Postmaster remuneration.
At a central level the detailed information collected by the Transaction
Management Service will enable the production of a wide variety of reports and
management information. In particular TMS will produce information to assist
and facilitate the distribution system.
It is important to state that the infrastructure does not restrict the means by
which POCL can process the information collected. Standard reports will be
developed and a variety of ad hoc reporting can take place.
HARDWARE AND PERIPHERALS
INTRODUCTION TO HARDWARE AND PERIPHERALS
Pathway will use the combined Intel and Microsoft product set for
implementation of the Transaction Management Service and the counter
interface. This combination reflects a very cost-effective solution. Pathway is
unconstrained in the choice of equipment and will deliver equipment from any
manufacturer, that reflects the best value for money while giving due
consideration to the environmental, health and safety, ergonomic and
performance factors.
TMS HARDWARE
The message replication architecture employed within TMS enables its capacity
to be adapted to meet required transaction loads by increasing or decreasing the
number of correspondence servers supporting the post office branches. In
addition the capability of individual correspondence servers may be extended by
substituting larger Intel series processors.
It is envisaged that initially such servers will be based on dual Pentium
processors with evolution to 2- or 4-way Intel P6 processors. For counter
transactions, correspondence servers based on Pentium processors can support
between 1000 and 2000 counters per server depending upon the precise
transaction mix and rate, whilst providing full transaction replication, back-up
and recovery facilities. Such servers are Configured with RAID disk storage
subsystems.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 38 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
- Si Y
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE
4.3.7.3 COUNTER INTERFACE HARDWARE AND PERIPHERALS
4.3.7.3.1 The following represents examples of the counter hardware that Pathway
envisages using to meet the needs of the POCL counter automation strategy.
Pathway anticipates final selection of specific devices will take place following
the pilot demonstrator phase and discussions with BA and POCL.
Baseline Proposal Illustrative Technology
At each Counter :
ICL ErgoPro e440/66 running Windows NT
Counter PC and comprising :
Intel DX2-66 processor, 16MB RAM, 540MB
Hard Disk, four ISA slots, two I/O interfaces,
LAN card
Colour Monitor ICL 9” SVGA colour monitor
Keyboard Compact Keyboard from Alphameric
Counter printer Ithaca 5Oplus , a tally-roll impact printer
Reader devices DOCUmatic 7000 - a combined motorised
(Mag. Stripe, Bar Code, I reader for multiple font OCR, Magnetic
OCR and Smart Card stripe, MICR and attached bar code wand.
reader/writer) (Smart card reader/writer to be incorporated.)
At each post office :
Back office printer Fujitsu DL3700 dot matrix printer
ISDN card Eicon DIVA
4,3.7.3.2 Pathway can also provide a number of options to the counter devices above.
These include touch screen monitors, thermal printers, combined counter
printers (forms, receipt and slips). There are also a number of combinations for
the reader devices both in their physical position (associated with the keyboard,
associated with the monitor), and in their technical specifications (2-D bar
codes).
Annex 4 provides further details of the above equipment and options.
4.3.7.4 COUNTER INFRASTRUCTURE OPTIONS - F85 TERMINAL
4.3.7.4.1 The counter infrastructure proposed is based upon the Microsoft operating
system and Intel processor family of products. This approach provides POCL
with the widest range of options in relation to peripherals and application
software. The use of this combination of products provides POCL with great
flexibility in particular ;
¢ Access to a wide range of peripheral equipment
* Scaleable architecture
* Wide availability and skills for application development
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 39 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4,3.7.4.2
4.3.7.4.3
4.3.7.5
4,3.7.5.1
4.3.7.5.2
4.3.8
4.3.8.1
In smaller post offices it may be difficult to justify investment in such premier
infrastructure when transaction volumes are considered. In the absence of
funding from the EU for rural infrastructure it may be appropriate for POCL to
consider other infrastructure options.
Several options has been investigated by Pathway and one option in particular
merits further consideration. This option proposes to use a small low-cost
integrated terminal called an F85 supplied by De La Rue Fortronic. This
terminal will provide the capability to smaller offices to automate a selected set
of products. The terminal supports magnetic-stripe, smart-card and bar-code
reading. The terminal, which is programmed in standard C, will be integrated
into the Riposte architecture by using a simpler version of the journal server.
The same message replication facilities will be supported by the terminal. The
complete details of the terminal and its applications is provided in Annex 4 -
Baseline Proposal Summary and Options.
POST OFFICE BRANCH NETWORK
Each post office will have an ISDN 2 link to the branch network, giving each
office two high-speed channels (2 x 64 kbit/s) for data, or voice traffic (very
large post offices may have a second ISDN 2 line). The correspondence server
backbone network will support multiple ISDN 30 connection points (each
providing 30 channels) to ensure ample channels are available to support post
offices during peak periods.
ISDN provides a particularly good fit to the style of working within post offices.
The fast call set-up and the fast and reliable operation result in short calls being
made during typical counter operations without any perceived delays. Lines do
not have to be kept open while lengthy transactions are completed, and a tariff
structure based on per second charging means that call charges are kept to a
minimum. The high speed available with ISDN means that additional benefit
can be achieved by saving non-urgent data within the POCL counter
infrastructure until connections have been established for an urgent
transmission, and then transmitting a small burst of this data on the back of the
primary transmission. This is referred to as ‘trickle - feeding’ transactions.
SATISFYING BA/POCL INFORMATION NEEDS
Every transaction at the counter interface places a message in the journal
message store. In this context the word ‘transaction’ is used to describe
interactions that do not necessarily involve movement of cash across the
counter. An example of such a transaction is a request from a benefit customer
for a statement, or for posting interest to a savings account. The Riposte
architecture offers BA/POCL the ability to capture and track all transactions.
Having this information for non-cash transactions will allow both BA and POCL
to analyse how the population of customers behave and provide further
information on the patterns and trends within the customer base.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 40 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
iw
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.8.2 Every transaction has a unique transaction identifier that incorporates the date,
the time, the place and the counter staff ID.
4.3.8.3 Following tables show the information needs and how they are addressed, based
on the SSR requirements articulated in Chapters 4.2.4.3.4 and 4.2.4.6.3.
43.8.4 Table of Information Needs for Financial Control
SSR I This SSR requirement Will be made I Comment :
Ref : I (See Chapter 4.2.4.3.4) : available
(Yes/No)
(a)_I Value of each transaction YES Captured at the counter
(b) I Volumes of transactions YES Summaries produced at each
post office. National
summaries may also be
produced
(c)_ I A unique code for each YES Unique codes for each of the
product so that detailed products is implemented
product information can be within each of the counter
made available across all applications and is captured
clients. as part of every transaction
For example, the need for a
breakdown of sales of Royal
Mail stamps by
denomination
(d) I Source (i.e. outlet YES Full details of outlet and
identification) counter staff is provided
(e) I Client reference and client YES This is captured as part of the
scheme or product reference details of each transaction
for each transaction
(f)_ I Customer identification and YES This ‘personal details capture’
details is implemented ona
For example, for transaction basis as needed
transactions involving and is captured as part of the
cheques, passports, motor transaction record
vehicle tax discs
(g) I Method of payment YES Multiple payment methods
are supported for each
transaction
(h) I Date and time of the YES
transaction
Pathway Response to
COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN.
Page: 41 of 44
Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
4.3.8.5 Table of Information Needs for Internal Control
SSR This SSR requirement Will be made I Comment :
Ref: I (See Chapter 4.2.4.6.3): I available
(Yes/No) —
(a) I POC and agent YES
transactions separately
identifiable . i .
(b) Capture of data at the YES Each transaction has x.eiaue,
outlet is complete, I serial number i
accurate and robust, For 1
example, there is a unique
reference per transaction __
© Any transfer of data to and YES Use of CRC and digital
from a central location signature ensures that the
(repository) is complete, transaction is transmitted
accurate and robust without loss of integrity
(d) Whether off- or on-line, YES This is implemented at the
the system must be capable application level
of validating transactions
by format and value
(e) In the event of fraud it can YES Use of status messages in the
be proved that the system journal file indicate the health
was operating without of the system at defined time
defect intervals
( Transaction receipts YES Inherent in the Riposte
(identifying a specific architecture is the ability to
client) are automatically recover without resorting to
generated for customers paper
and also retained to allow
recovery, if there is a
failure between back-up
cycles
(g) Accountability for cash, YES Some development is required
stock and any supporting
documentation is retained
by each outlet and
individual clerk, where
appropriate
(h) The method of payment is YES Multiple payment methods
recorded at the point of are also supported
sale
(i) Access to the system, and YES One-way password
to certain functions within encryption is supported. User
the system, is restricted types are definable and all
and a user log is user interactions with the
maintained system are recorded
() Appropriate back-ups are Not I No user back-ups or
taken, including a needed I automatic back-ups take
complete record of daily place, due to the replicated
transactions messaging architecture
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 42 of 44
OJEC Notice 94/S 165-58937/EN
Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4,3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
SSR
Ref
This SSR requirement
(See Chapter 4.2.4.6.3) :
Will be made
available
(Yes/No)
Comment :
(ky
An independent or
supervisory approval is
necessary to amend or
cancel transactions after a
certain stage in the
processing
YES
Implemented by access
control. User type
‘SUPERVISOR’ is required to
reverse or cancel transactions
after a certain point.
@
Both operator and device
are uniquely identified
within each outlet
This is provided and is
captured as part of the
transaction record
(m)
Data should undergo a
balancing procedure to
enable a final review and
authorisation
YES
(n)
All transactions are
collected using a secure
method at the earliest
opportunity
The transactions are
replicated to the central
location as communications
are established
(0)
Transactions not collected
from previous days are
clearly identifiable
YES
©)
All transactions can be
reconciled to an
appropriate supporting
voucher depending on the
transaction type. Where
necessary, these vouchers
must be available for
central validation of
amounts collected
(a)
The system should
maintain an up-to-date
record of cash and stock
on hand for audit
purposes and be capable of
reporting current balances
Some development is required
see (g) above
(rt)
All transfers to and from
other offices and between
staff are clearly identifiable
(8)
All specified summaries are
produced automatically
when required and include I
all transactions processed
since the last summary was
completed
A batch summary can be
produced automatically. Full
summaries can be produced
on demand
(t)
Items posted to suspense
accounts can be identified
for future investigation
YES
Reversals are logged in full in
the journal
Pathway Response to
COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN
Page: 43 of 44
Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
are:
SECTION 4.3 - POCL STRATEGIC INFRASTRUCTURE SERVICE
[SSR I This SSR requirement Will be made I Comment:
Ref: I (See Chapter 4.2.4.6.3): I available
(Yes/No)
(u} Information to show YES Full hardware specification is
compliance with relevant available in Annex 4.
legislation. For example,
Health and Safety, Data
Protection Act, Companies :
Act —— ee netmannnaen v0 wtyanovmmnnad
(v) An outlet can continue to YES it aeallysis’ of faibare:
operate and maintain an seuaatios 13 cosisiaered in {
audit trail in the event of Section 5.5.
system failure I I
4.3.9 POCL STRATEGIC INFRASTRUCTURE - SUMMARY
4.3.9.1 The strategic infrastructure proposed by Pathway will enable POCL to automate
all transactions at the counter. The infrastructure is based on the Riposte
product, a robust and proven software platform. Use of Riposte will provide a
high degree of resilience and unattended recovery in the event of an
infrastructure failure.
4.3.9.2 The automation of transactions will be based on a generic approach which will
implement a set of applications that are highly configurable by the use of
parameters, supporting the rapid development and roll-out of new business
transactions,
4.3.9.3 The automation platform will embrace industry-standard products, specifically
the Intel and Microsoft product set. This infrastructure is a living and
developing system of hardware and software which future-proofs the investment
and will allow new technology peripherals to be exploited as needed to support
business development.
4.3.9.4 The Transaction Management Service will guarantee the transaction information
from its capture at the counter to its final delivery to the client. All information
to provide a full audit of the transactions is provided within the service. Client
needs and internal POCL information needs are satisfied by a set of functions
that link POCL to its clients, in accordance with client requirements.
4.3.9.5 The counter infrastructure, (the point of delivery of customer service to the
public) can be used by a wide range of staff and will enable the delivery of
quality customer service. Customers’ perceptions are generally formed at the
counter and the infrastructure will deliver speedy and accurate transactions to a
very high standard across all counter products.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 44 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
TABLE OF CONTENTS
SECTION 4.4 TABLE OF CONTENTS
4.4 BENEFIT PAYMENT SERVICE
4.4.1 INTRODUCTION ..
4.4.2 OVERVIEW OF THE. BENEFIT PAYMENT ‘SERVICE.
4.4.2.1 INTRODUCTION TO PATHWAY’S BPS PROPOSAL.
4.4.2.2 OVERVIEW OF THE CARD MANAGEMENT SERVICE ...
4.4.2.3 OVERVIEW OF THE PAYMENT AUTHORISATION SERVI
4.4.3 CARD MANAGEMENT SERVICE.
4.4.3.1 CMS OBJECTIVES...
4.4.3.2 CMS INFORMATION FLOWS
4.4.3.3 CMS INTERFACES .
4.4.4 CMS FUNCTIONS...
4.4.4.1 SUMMARY OF CMS FUNCTIONS
4.4.4.2 RECEIPT OF INSTRUCTIONS FRO!
4.4.4.3 CARDHOLDER DATA BASE...
4.4.4.4 CARD PRODUCTION AND PERSONALISATIOI
4.4.4.5 CARD DESPATCH ..
4.4.4.6 CARD COLLECTION ‘AND "ACTIVATION...
4.4.4.7 LOSS, THEFT, DAMAGE AND. REPLACEMENT I OF CARDS
4.4.4.8 INVALIDATION AND SUSPENSION ..
4.4.4.9 TEMPORARY TOKEN TO SUPPORT EMERGENCY PAYM ENTS
4,4.4.10 CARD MANAGEMENT ENQUIRIES AND INFORMATION NEEDS
4.4.4.11 CHANGE NOMINATED OFFICE.......++es+0e
4.4,4.12 CATERING FOR SPECIAL NEEDS GROUPS.
4.4.4.13 CARD MANAGEMENT HELP DESK.........
4.4.5 CARD-BASED BENEFIT PAYMENT PROCESS
4.4.5.1 INTRODUCTION TO CARD BASED BPS.....
4.4.5.2 PAYMENT AUTHORISATION SERVICE (PAS).
4.4.5.3 RECEIPT OF AUTHORISED PAYMENTS FROM CAPS.
4,4.5.4 DISTRIBUTING DATA TO THE POINT OF ENCASHMENT.
4.4.5.5 APPLYING PAYMENT AND CARD STOPS ossessseseseeee
4.4.5.6 CARD AUTHENTICATION AND CARDHOLDER VERIFICATION.
4.4.5.7 IDENTIFICATION OF BENEFITS PAYABLE
4.4.5.8 RECEIPTS...
4.4.5.9 STATEMENTS.
4.4.5.10 EXCEPTION PROCESSING.
4,4.5.11 NOTIFICATION OF ENCASHMENT AND EXPIRY TO CAPS.
4,4,5,12 NOTIFICATION OF EXCEPTIONAL CARD USAGE
4.4.5.13 AUDIT TRAILS .....ssssecsseeseeee
4.4.5.14 BENEFIT AGENCY ENQUIRIES.
4.4,.5,15 SECURITY sessseseees
4.4.5.16 COUNTERFEIT CARDS
4.4.5.17 RECONCILIATION...
4.4.5.18 PHYSICAL ATTRIBUTES OF PAS
4.4.6 THE MIGRATION OF THE BA CARD..
4.4.6.1. PATHWAY’S SMART CARD CAPABILITY .
4.4.6.2 PATHWAY'S SMART CARD PRODUCTION CAPACT
4.4.6.3 PATHWAY’S EXPERIENCE IN SMART CARDS
4.4.6.4 PATHWAY SMART CARD REFERENCES....
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
4.4.7 CUSTOMER ACCEPTABILITY ....
4.4.7.1 INTRODUCTION TO RESEARCH
4.4.7.2 BACKGROUND ATTITUDES
4.4.7.3 OPINION FORMERS...
4.4.7.4 ATTITUDES TO BENEFIT COLLECTIONS
4.4.7.5 SAFETY, SECURITY & FRAUD ..
4.4.7.6 RESEARCH RECOMMENDATION:
4.4.8 CONFIGURATION MANAGEMENT ..
4.4.8,1 INTRODUCTION TO CONFIGURATION MANAGEMENT
4.4.8.2 PATHWAY SERVICE MANAGEMENT.
4.4.8.4 SECURITY KEY DISTRIBUTION .
4.4.9 REQUIRED DEVELOPMENT......
4.4.10 SUMMARY OF BENEFIT PAYMENT PROPOSAL .
38
39
39
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4
4.4.1
4.4.1.1
4.4.1.2
4.4.1.3
44.2
4.4.2.1
4.4.2.1,1
4.4.2.1,.2
BENEFIT PAYMENT SERVICE
INTRODUCTION
This section describes Pathway’s proposal for the Benefit Payment Service (BPS).
It provides an overview of the proposed service followed by a description of the
major components of the BPS. The section is organised as follows :
* A summary of the complete BPS and how this maps onto the BA critical
success factors
¢ An overview of each component that makes up the payment process
The principal items discussed are :
* The Card Management Service and card production processes
¢ The complete card-based benefit payment process
¢ The migration path for the BA card
* Pathway’s recommendations on the customer acceptance issues
Pathway’s approach to the BPS is based on the recognition that benefit payment
is an entitlement and that the system must enable payment with a very high
degree of reliability at all times.
OVERVIEW OF THE BENEFIT PAYMENT SERVICE
INTRODUCTION TO PATHWAY’S BPS PROPOSAL
Pathway’s mission in relation to benefit payment is to provide a fraud-resistant,
secure, auditable and fully reconcilable service.
The Benefit Payment Service consists of the two major components :
* Card Management Service (CMS)
* Payment Authorisation Service (PAS)
These components are shown in Fig. 1.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
oe
SECTION 4.4 - BENEFIT PAYMENT SERVICE
Fig. 1 - The BA/POCL Procurement Service Boundary
4.4.2.1.3 Both CMS and PAS are within the overall Procurement Service Boundary. CMS
lies wholly outside the POCL Strategic Infrastructure but PAS on the other hand
utilises a component of the Strategic Infrastructure for distribution of payments
and payment encashment at the post offices.
4.4.2.1.4 Pathway will implement these two major components as discreet entities
allowing the Benefit Agency flexibility for future change within these systems.
The boundary between the systems will be distinct and secure,
4.4.2.1.5 The scope of the BPS encompasses PAS, the interface to CAPS, the card
management system, and the POCL Strategic Infrastructure. The solution where
possible is based on proven components minimising risk and supporting the
achievement of the following BA critical success factors :
This BA critical success factor : I Will be given this Pathway support :
Public acceptability. The Pathway has conducted market research which
proposed method must be has provided valuable information on issues
acceptable to customers, including I affecting acceptability. The research results will
the disabled be used to ensure public acceptance while
catering for the business needs of BA
Reduce and contain fraud Pathway is proposing an industry-standard
plastic payment card which will be used as the I
token for positive authorisation of every
benefit payment. The end-to-end service will
be fully auditable and support robust card
authentication and customer verification
procedures to contain fraud
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
This BA critical success factor :
Will be given this Pathway support :
Reduce administration costs
The Pathway solution offers an electronic
information and payment system which will
reduce the need for paperwork and provide a
speedy end-to-end process
Allow complete accounting
including reconciliation to
individual payments
The Benefit Payment Service will allow
individual payments to be audited fully at all
stages in the payment life cycle from
authorisation and dispatch from CAPS through
to encashment and return of cashed and
uncashed details to CAPS.
Transfer of operational and
encashment fraud risks to
contractor
Pathway will use the experience and resources
of its shareholders in the area of fraud
reduction to minimise the risk of fraudulent
encashment. Pathway will accept these risks in
accordance with agreed procedures
Maximise the opportunity to pay
for the service on a usage basis
The system will provide the necessary
accounting and management information to
facilitate a reconcilable payment for the service
ona usage basis
Fast and early roll-out of the
service so that early advantage can
be taken of the projected financial
benefits
Pathway has proposed a solution that builds
upon components already in use. By re-using
proven components at all levels of the total
service, Pathway will be capable of providing a
FUJ00098232
FUJ00098232
fast and early roll-out.
4.4.2.1.6 Pathway’s proposal for BPS supports resilient and cost-effective automation of
the existing and anticipated new and varying benefit types required. It takes full
account of the unique characteristics of benefit payments which distinguish it
from the more conventional centralised credit/debit card operation. The key
difference is the fact that the timing, value and location of benefit payments are
usually known, and the delivery of the payment has to be guaranteed. In
contrast, timing, location and value are largely unpredictable and there is no
right to payment with a conventional card operation. Thus, the requirement is
for a different solution.
4.4.2.1.7 _ Pathway is also sensitive to the needs of special groups such as the homeless and
those who do not speak English. Our solution will ensure that the interface to
these groups, whether by mail, over the telephone or at the post office counter,
is agreed with BA and is tailored to suit their special needs.
4.4.2.2 OVERVIEW OF THE CARD MANAGEMENT SERVICE
4.4.2.21 The complete BPS is based on the principle of positive authorisation at the point
of benefit encashment. Pathway totally embraces BA’s requirement to pay the
right benefit to the right customer at the right time and to minimise the number
of failures in this area.
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE Page: 3 of 44
Date: 08/06/95
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.2.2.2
4,4.2.2.3
442.24
4.4.2.3
4.4.2.3.1
4,.4.2,3.2
4.4.2.3.3
To achieve this Pathway will provide cards that are :
* Based on recognised international standards
* Secure against manipulation
The cards themselves have no intrinsic value as they :
* Do not contain information about benefit payments
* Do not reveal the benefit recipient’s nominated post office
* Do not contain personal details for authentication (these are held on the
system)
The cards will be supported by a Card Management Service (CMS) which has
the following characteristics :
* It will use ACI’s GENcard card management system
* It is capable of handling the projected volume of cards
* It provides a totally secure and well-proven card production and
personalisation service provided by De La Rue
* It uses the best industry practice for card pick up and management of lost,
stolen and re-issued cards
OVERVIEW OF THE PAYMENT AUTHORISATION SERVICE
The Pathway solution will accept individually authorised payments from CAPS
and distribute these payment details to the point of collection (in this case the
benefit customer’s nominated post office). The Pathway solution will support
encashments away from the nominated post office and will also cater for the
conditions created by proxy payments.
Within the Pathway service the delivery of benefit through the issue of tokens
(e.g. milk tokens) is not materially different from payments in sterling.
Payments authorised through CAPS will identify the currency. of payment as
sterling or tokens. Throughout this section, payment ‘value’ should be
interpreted as meaning either sterling or token.
Automation of benefit payments through the POCL Strategic Infrastructure is a
major task. Pathway understands the BA’s vision and will implement a system
that enables BA to achieve its business objectives. The Payment Authorisation
System will have the following set of characteristics :
* Accustomer payments database
¢ Easy access for real-time stop placements and enquires
* Integration of the varying components of card management, payment process
and counter infrastructure
+ A method of payment which ensures payment of the right money to the right
person at the right time
¢ A mechanism to ensure that the payment is made only once
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
i
SECTION 4.4 - BENEFIT PAYMENT SERVICE
« Asecure approach that will reduce fraud
* Controls to detect and monitor unauthorised activity and supply evidence to
support prosecutions involving fraudulent transactions
« Full accounting and reconciliation facilities at an individual payment level
* Ability to pay all of a person’s benefit entitlement(s) in one transaction using
a single token or card
4.4.2.3.4 PAS will be supported by a central system provided by Alliance & Leicester
(A&L) called the Payment Management System (PMS) and a proven counter
infrastructure called Riposte. Riposte is the basis for the POCL Strategic
Infrastructure and is described in Section 4.3.4.2. The PMS proposed by
Pathway is again based on components in use as part of the girocheque
reconciliation system. PAS will provide :
* The capability to handle the projected volume of payments
* A secure and well-proven method of payment
* Asingle and complete information source for a customer’s payment
* A strategic and well-understood migration path including the migration to a
multi-purpose smart card
4.4.3 CARD MANAGEMENT SERVICE
4.4.3.1 CMS OBJECTIVES
4.4.3.1.1 The overall objective of CMS is to ensure that authorised cards and tokens are
issued only to approved customers and their agents, and that they are only
available for use for customers to receive authorised benefits. This is made up
of the following objectives :
* To supply, personalise and distribute the card, and monitor its status
throughout its life-cycle
* To receive initial instructions from CAPS and the determine the need to
renew the card without further reference to CAPS
* To receive personal details that are appropriate to the use of a card from
CAPS, and be capable of receiving details from other sources
* To provide card management services for purposes other than benefit
payments
* To maintain timely data on cards and temporary tokens
4.4.3.2 CMS INFORMATION FLOWS
4.4.3.2.1 The overall information flows into and out of CMS are shown in Fig. 2 below.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
Enquiries,
lest cards,
card ops
I Card invalidation,
suspensions & lifting,
I te replacements
Eng —~
lost, found I. pe,
reporting toms
jem
Card details
(for payment enrichment)
PUN delivery
to customers
BA vq.
Urgent incidents &
routine reports
8 coaracn I
Card Delivery
to post offices
Counter lnfrastructare
Fig. 2. - CMS Information Flows
4.4.3.3 CMS INTERFACES
4.4.3.3.1 Details of the service interfaces that affect CMS are contained in Section 4.2.12.
In summary they are :
(a) CMS to CAPS - This is an external interface which supports the transfer of
cardholder information using file transfer.
(b) CMS to POCL Strategic Infrastructure - This is an internal interface between
CMS and TMS. TMS in turn then provides a connection to the POCL
counter interface. This interface will support file transfer and real-time
transactions including card stop lists, card batch acceptance and card
activation.
(c) CMS to benefit office - This is an external interface which supports
interactive access from BA. This will support enquiries from BA on card
status and enable the placement of stops.
(d) CMS to benefit customer - This is an external interface which comprises
two forms of communication. The first enables BA customers to advise
Pathway of card loss, theft or damaged. This service will be provided by the
CMS help desk which is supported by the Pathway Call Reception Centre.
The second defines how CMS will distribute card pick up notices PUNs to
BA customers.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.44
44.4.1
4A ALL
4.4.4.2
4.4.4.2.1
(e) CMS to PMS - This is an internal interface and provides a formal boundary
between the card and payment management services. The two functions
supported are :
(i) PMS access to card verification data during the processing of payment
records.
(ii) A transactional interface to enable CMS to update the payment status
immediately following reports of card stops or monitoring events.
(f) CMS to Card production - This is an internal interface which will use a
secure communications link to pass card production details to Pathway’s
subcontractor for card production.
CMS FUNCTIONS
SUMMARY OF CMS FUNCTIONS
Building on the CMS overview presented in Section 4.2.7 the functions
provided by CMS are summarised below and will be explained in detail in the
following sections :
* Receipt and validation of new cardholder details
* Creation of a cardholder database, generation of card orders and pick up
notices
* Card production and personalisation
* Distribution of cards to post offices
* Card collection and activation
* Loss, theft, damage and replacement of cards
* Setting card stop and alert status
* Issue of cards for emergency payments
* Support for authorised card enquiries and card usage histories
* Changes of nominated post office
* Catering for special needs groups
* Provision of a help desk service
RECEIPT OF INSTRUCTIONS FROM CAPS
CAPS will create a new cardholder notification which will be received by CMS.
This information will be sufficient for CMS to create an entry in the cardholder
database and for CMS to create a card for the customer.
The Benefit Agency has specified in the SSR the information that will be
available to CMS from CAPS :
For each initial card issue request :
1. Customer National Insurance Number
2. Customer name (as requested by the customer to be displayed
on the card)
3. Correspondence address
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 7 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4,4.4.2.2
4,4.4.2.3
4.4.4.3
4.4.4.3.1
4.4.4.3.2
For each initial card issue request :
Nominated post office ID (if appropriate)
4.
5. Card type (e.g. WPA card)
6
National Sensitivity Indicator
Pathway will dispatch cards to post offices for pick up and therefore CAPS must
provide the nominated post office ID. Additional information may be required
for special groups, for example the blind or the illiterate (where a normal PUN
would be inappropriate) or a language indicator (for example Welsh).
This information will then be processed by CMS to create the entry in the
cardholder database. This processing will validate the information received and
create the information which will eventually be embossed and encoded onto the
card during personalisation.
CARDHOLDER DATA BASE
Pathway has selected the GENcard Card Management System from Applied
Communications Incorporated (ACI) to manage the customer database and the
cards through their life-cycle. Internationally over 400 organisations in 54
countries rely on ACI software, and between them they have over 1000
applications installed. I ACI's success is built on the supply, support and
development of standard software packages. Financial and retail organisations
worldwide have benefited from the speed, security, reliability and
comprehensive features of ACI’s card management applications.
Functionality Provided by the ACI Card Management System
The card management system is designed to meet the needs of financial
institutions and retailers who issue cards or acquire card transactions, or both.
The GENcard system will provide Pathway’s solution for the following
requirements of the Card Management Service :
(a) Maintenance of a database of customer details. These are initially received
from CAPS and periodically updated by CAPS or from the counter
infrastructure or the help desk.
(b) Provision of information for the creation of the personalised card and pick
up notice (PUN). The card will be supplied in an appropriate card wallet
and the PUN will tell the customer how to collect the card.
(c) Managing the ongoing maintenance of card status.
(d) Making the card, personal and status details available to the payment
authorisation system for onward routing to the post office for use in
payment authorisation and encashment.
(e) Recording and actioning instances of loss, theft and damage to cards.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 8 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.4.4 CARD PRODUCTION AND PERSONALISATION
4.4.4.4.1 This section gives an overview of the total card production and personalisation
service offered by Pathway. The section steps through each of the stages to give
BA
a complete understanding of the high quality and secure process involved.
The production and personalisation process and materials chosen by Pathway
are
of the highest standard and will help to achieve the goals of customer
acceptance.
4.4.4.4.2 Card Manufacturing
{a)
(b)
Pre-Press and design
Pathway is offering BA the full benefits of the card industry’s most advanced
digital pre-press and origination facilities. The De La Rue Card Technology
pre-press department is fully equipped with digital technology based upon
Apple Macintosh hardware. This hardware is linked to a high-resolution
scanner and outputs to a state-of-the-art image setter which ensures that the
film work produced for card production is of the highest quality.
The pre-press system offers the facility for the receipt and exchange of
electronic data which provides a rapid and reliable link between BA’s design
agency and Pathway’s card production site.
Pathway can offer the BA :
(i) De La Rue’s industry-renowned skills and expertise in the production of
anti-counterfeit designs and card features.
(ii) De La Rue’s ability to produce holographic security features. A set of
specimen cards are shown in Annex 9 - Technology Trends.
Pathway also offers multiple proofing formats to BA as part of the process.
Pathway proposes full proofing on the plastic card.
Card Printing
Pathway offers to BA/POCL, De La Rue’s unique experience in the use of
four- and five-colour lithographic presses fitted with the latest press
controls,
Pathway Response to
COMMERCIAL IN-CONFIDENCE Page: 9 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE,
(c) Card Finishing
De La Rue has developed a number of innovative processes to ensure
quality is maintained through all the finishing stages. By working closely
for a number of years with its suppliers of plastics, inks, signature panels,
holograms, magnetic media, and smart card components, De La Rue is
achieving a consistent quality product which is renowned in the plastic card
industry. Specimens of the cards are included in Annex 9.
4.4.4.4.3 Card Personalisation
(a) Receipt of Data
The information required to personalise the cards will be provided by CMS.
The information will be transferred to De La Rue’s computer system by
secure electronic link. For each customer the following information is
passed to the production process :
(i) Original information from CAPS :
* Customer National Insurance Number
¢ Customer Name
* Correspondence address for the PUN
« Nominated post office ID for card dispatch
* Card Type (e.g. WPA card)
¢ National Sensitivity Indicator
(ii) Information supplied by CMS (required for card activation and
verification) :
¢ Primary Account Number (PAN) - this will incorporate the NINO
¢ Card Activation Number (CAN) - a four-digit number which is printed or
barcoded on the PUN and used to activate the card
* Card Issue Number (CIN) - a sequence number for the card. This
number is incremented each time the card is replaced or renewed
* Sherman Number - a number unique to each card which is used as an
additional security device
This additional information generated by CMS is required as part of the
card activation and verification process.
(b) The Standard Personalisation Processes
The printed base card is embossed and the magnetic stripe is encoded. It is
then matched to a personalised carrier by machine reading the magnetic
stripe and comparing it with a pre-printed code on the carrier.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 10 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
The matched card is then inserted into an envelope together with
information inserts, sealed and prepared for despatch.
Pathway can also accommodate a request from BA to cancel a card before it
is despatched to the nominated post office. De La Rue’s system is designed
to accommodate late cancellation requests. The record can be removed
from the data file prior to personalisation or the personalised card in its
carrier can be extracted prior to enveloping.
(c) Personalised card details
After the card has been personalised the card will contain :
(i) Embossed on the front of the card
16 digit ‘unique’ Primary Account Number (PAN) incorporating the
NINO
Title, and cardholder name (customer’s requested name as specified by
CAPS)
NINO
Card Issue Number (CIN)
Valid to date
(ii) Magstripe (Track 2) on the back of the card
Check Digit - MOD11
Card Issue Number
Expiry date
Service Code
Sherman security value
(iii) Paper Signature panel on the back of the card
Indent printing of the primary account number into the paper signature
panel.
(iv) Printed on both sides of the card
In addition to the above, Pathway will pre-print additional information
on the base plastic to assist BA customers in using the card and the help
desk services. Statutory declarations will also be agreed with BA and will
be printed on the card.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 11 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.4.4.4 Personalisation by Benefit
Pathway recognises the importance of gaining the acceptance to the BA card of
all groups of beneficiaries. An important step in achieving this may be to
personalise the card and PUN for some specific benefit types using different
colours, literature content and card design. Such groups might include War
Pensioners and customers in Northern Ireland amongst others. Pathway would
be pleased to discuss with BA how such designs should be developed and the
specific information required from CAPS to enable this.
4.4.4.4.5 Service Levels - Card Production & Personalisation
Pathway will meet agreed BA/POCL service level requirements. Detailed below
are suggested turnaround times for a volume of 50,000 magnetic stripe cards per
day over a three-year roll-out period. (Numbers in excess of 50,000 per day
will be agreed with BA). Pathway will work with BA/POCL to review any
necessary alterations in the production schedule.
(a) Proofing
Indicative proofing times are given from digitised artwork :
¢ Bubble jet proof =1-2 days
* Cromalin proof =5 days
* Plastic proof = 8 days
(b) Card Manufacture
Pathway require a period of eight weeks from customer-proof approval to
allow sufficient base stock to be generated for the personalisation of
50,000 cards per day.
After the initial eight weeks the base stock will be printed in weekly
batches to meet the daily demand. Card manufacture is not a critical
activity as the base stock can be printed in large volume runs and stored
securely until required for the daily personalisation runs.
(c) Card Personalisation
Pathway will guarantee lead times and our capacity for card personalisation
services for this contract, providing we have a clear understanding of
volume commitment in advance of commencing production.
Pathway proposes that BA commit to an annual volume for the contract
life. For card personalisation Pathway suggests the following two levels of
service to BA/POCL :
(i) Replacement (lost or stolen) cards
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 12 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.4.5
4.4.4.5.1
44.4.5,2
4.4.4.5.3
4.4.4.5.4
4.4.4.6
44.4.6.1
Cards will be despatched 24 hours from the receipt of replacement
request from the card management system
(ii) Routine renewals
Cards despatched within fifteen working days of receipt of data
from the card management system.
CARD DESPATCH
Once the customer record has been created on the card management system it
will generate a data file for transmission to the card production system. The
information provided will be sufficient to personalise the card and its associated
personalised carrier and provide details for generating the PUN. When
dispatched, the cardholder database within the card management system will
reflect the fact that the card is in production. The card status will then be
updated at the relevant points in the production and activation process.
Card despatch is carried out to an agreed schedule. De La Rue will pack the
cards into postal boxes and inform the security officers. The boxes are released
to the authorised distributor and De La Rue’s security staff will verify and
document all card orders leaving the premises.
As part of the secure delivery process Pathway will deliver the inactive card to
the nominated post office and send a PUN to the benefit customer. The PUN
will contain an encrypted and machine-readable post office ID number and a
visible and machine-readable CAN. Encoding these fields will allow electronic
capture of the information at the post office. The use of an encrypted post
office ID will provide an additional security check which will highlight any
attempt to collect a card at the wrong post office.
The nominated post office Postmaster will be required to sign for a batch of
cards in their sealed carriers. The post office will then register each of the
batches received together with the post office ID which will be barcoded on the
card batches. This information will be returned to CMS where it can be used to
support queries on card status and location.
CARD COLLECTION AND ACTIVATION
Pathway will use a Card Activation Number (CAN) as part of fraud management
during the card activation process. The CAN will be generated by CMS and
passed to card production. The CAN will then be printed on the PUN and
dispatched to the customer.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 13 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
AS ho ff
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.4.6.2
4.4.4.6.3
4.4.4.6.4
444.65
4,4.4.6.6
4.4.4.6.7
In addition to generating the CAN, Pathway will generate a non-computable
ten-digit value (known as the Sherman), which is unique to each card. This
value is held in CMS, is associated with the distributed payment records and is
held within the magnetic stripe of the card. The Sherman value will be
compared whenever the card is used for payment. This added security will
reduce the risk of fraud and minimise the risk associated with any attempt to
introduce counterfeit cards.
The customers will present the PUN at their nominated post office, together
with an independent means of identification. The counter staff will retrieve the
card, swipe it and then scan/input the CAN. On input of the CAN, a secure
algorithm computes the CAN from information on the card and compares it
with the one entered. Having verified that the CAN is correct the customer will
be asked to sign a receipt and the card in front of the counter staff.
The card is now considered activated and its status returned to CMS. Collection
of authorised payments can proceed either immediately or as they fall due.
Using the experience of De La Rue and A&L, Pathway will develop a set of
procedures associated with the processing of cards, the managing of exceptional
situations and the provision of assistance to the counter staff.
These card procedures will include :
* Non-collection of cards
* Loss of the PUN
* CAN verification failure
¢ Failure to verify the identity of the customer
* Non-availability of the card when the PUN is presented
Card Dispatch and Activation - Special Cases
(a) In instances of homelessness, correspondence will be forwarded to the
benefit office or any address the BA choose to nominate in the personal
details.
(b) Pathway has identified additional information required from CAPS to
support production of a multi-lingual version of standard literature, such as
the card PUN.
(c) Pathway recognises the potential difficulties surrounding verification when
illiterate customers collect their cards. The same potential difficulties also
exist when they are making encashments.
At the present time customers making encashments with a girocheque have
their mark attested by a witness. Even with this procedure it is not possible
to confirm without doubt that the customer is who he says he is.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 14 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ie
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.4.7
44471
4.4.4.7.2
4.4.4.7.3
4.4.4.7.4
Pathway’s proposal places strong emphasis on the use of the nominated post
office, and for the majority of cases the illiterate customer will be known by
local post office staff. For new customers the use of a PUN provides a level
of protection and additional verification data (such as date-of-birth or
benefit type) could be used as additional checks,
The current arrangements for witnessing the customer’s mark can continue
if necessary.
(d) Pathway has a number of ideas which we wish to discuss with BA before
proposing a solution for illiterate customers. These include the use of
witnesses to the customer’s mark and the use of specific CAPS information.
(e) In those cases where customers are unable to collect cards in person,
Pathway offers for discussion the following additional options :
(i) Initial advice from BA of a new customer should include the list and
associated personal details of known agents who would be permitted to
collect the customer’s card.
(ii) Supplementary proof of identity should be presented at the time of
requesting card activation.
(iii) In the event that the agent requesting card activation is an established
payee in his or her own right, the agent’s card should be presented to
allow verification.
LOSS, THEFT, DAMAGE AND REPLACEMENT OF CARDS
The GENcard CMS was chosen for its capability, security and the ease with
which it can cope with the requirement for total card management.
The system and its operator must cope with circumstances such as loss, theft or
damage to cards. These situations result in the de-activation of cards and re-
issue of new cards. The complete process is supported by appropriate
operational and management reports, on a scheduled and ad hoc basis.
Apart from managing the card life-cycle process the overriding consideration in
these exceptional but expected situations is payment of entitled benefit to the
customer at the correct time.
Where a replacement card is requested as a result of reported loss, theft or
damage, the card PAN will remain the same, but the card issue number will be
incremented and new security values will be assigned.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 15 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
Periodic Card Replacement
4.4.4.7.5 It will be necessary to re-issue cards after a pre-determined period of time. The
renewal cycle will be optimised by monitoring card-read failures. Normally
bank cards are re-issued every two years but given the lower usage associated
with benefit payment cards Pathway recommends a three-year renewal cycle.
4.4.4.7.6 A replacement card will be issued one month before expiry of the previous card.
Pathway will ensure that the transition from the old card to the new card does
not impact upon the customer’s ability to collect benefit and will manage the
outstanding payments to reflect the incremented card issue number.
4.4.4.8 INVALIDATION AND SUSPENSION
4.4.4.8,1 On receipt of notification from CAPS or other sources of a card stop or a card
alert, CMS will record this status and will immediately advise PAS so that all
impacted payments can be treated appropriately. This is considered further in
Sections 4.4.5.10.8 to 4.4.5.10.11.
4.4.4.9 TEMPORARY TOKEN TO SUPPORT EMERGENCY PAYMENTS
4.4.4.9,1 Pathway recognise the requirement to issue emergency payments within very
short deadlines to customers some of whom will not have a BA card. Pathway
believe that the procedures for emergency payments should not jeopardise the
highly secure system that the Pathway solution provides for normal payments.
4.4.4.9.2 The procedures within PMS, CMS and at the post office counter should be fully
utilised to ensure that a fully reconcilable service is maintained and that new
opportunities for fraud are not introduced.
4.4.4.9,3 Pathway believe that the emergency payment procedure within BA offices
should be quick and simple to operate and be complementary to the increasing
visibility and usage of BA cards within normal BA office procedures.
4449.4 For those customers who posses a BA card the PAN is input to CAPS as part of
the emergency payment process at the local BA office. Additional cardholder
verification details will be added by CMS and the payment authorisation
transmitted to a nearby (or any) post office to facilitate speedy collection.
4.4.4.9.5 Where BA needs to make an emergency payment to a customer who does not
possess a benefit card, Pathway proposes a solution which would involve the
issue of a temporary single-use token.
44.4.9.6 The token could physically take a number of forms (secure paper, mag-stripe
paper card, mag-stripe plastic card) but each token should be :
* Valueless
* Obviously different in appearance to the BA card
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 16 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4,4 - BENEFIT PAYMENT SERVICE
4.4.4.9.7
44.4.9.8
4.4.4.10
4.4.4.10.1
* Uniquely identifiable
* Securely issued to BA offices
* Known to exist within CMS
* Capable of being stopped and suspended
* Have no purpose until explicitly input to CAPS as part of an emergency
payment
The precise emergency payment process will need to be agreed with BA but
Pathway envisage the following key steps :
(a) A stock of tokens would be issued to all BA offices. Each token would be
unique and would contain encoded information (i.e. Sherman value) to
protect against counterfeiting. Additional batches of tokens can be issued
automatically by CMS or explicitly ordered by each BA office. A secure
receipting process for emergency tokens is required to provide an audit trail
of tokens.
(b) An emergency payment is authorised at a BA office, a token selected and its
details together with the claimant details input to CAPS. It is only at this
point that the token has any purpose. The visible token reference number
will be keyed in, or machine read if more convenient.
(c) CAPS will issue an authorised payment to PMS and PMS will then route the
payment to the selected post office.
(d) The token is signed by the customer and issued.
(e) Upon presentation at the post office the normal counter procedure takes
place. The token is read and the encoded token number is used to retrieve
the payment details. The normal signature verification process will include
an additional check on information obtained at the BA office such as date-
of-birth.
(f) The temporary token can now be destroyed at the post office.
Pathway recognise that the introduction of tokens into BA offices will require a
new set of procedures to supplement the emergency payment process. Pathway
will be pleased to share its knowledge of card and paper handling procedures to
ensure that the design and use of the token provides an efficient and fraud
resistant emergency payment process.
CARD MANAGEMENT ENQUIRIES AND INFORMATION NEEDS
Pathway will provide BA with card status and cardholder details and any
available profile of card usage held on CMS. Historic actions against a given
card will be recorded on an events history and available for interrogation.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 17 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.4,10,2
4.4.4.10.3
4.4.4.11
4.44.11.1
4.4.4.12
4.4.4.12.1
4.4.4.13
4.4.4.13.1
4.4.4.13.2
4.4.4.13.3
This capability to service card queries is an established and proven element of
card operations within the ACI’s card management system proposed by
Pathway.
Changes to card status will be tracked to ensure compliance with the established
life-cycle and to inhibit or flag any activity which is abnormal. Reporting will be
geared to management of exceptions such as use of a monitored card or
infringement of restricted usage on a card.
CHANGE NOMINATED OFFICE
Pathway will enable change to the nominated office at the counter and onward
routing of this information to CAPS and CMS for immediate implementation.
Such change could be negated by CAPS in the event that the customer was
restricted to a particular post office.
CATERING FOR SPECIAL NEEDS GROUPS
Pathway recognises the importance of ensuring that the card management
system caters for all sections of society. Pathway’s market research (see Annex 8
- Research Programmes) has provided a significant insight into the needs of
many such groups. In particular Pathway is in discussion with RNIB and some
early thoughts are :
¢ The provision of a Braille logo on the BA card
* The provision of Braille PUNs
¢ The indication that a Braille statement is required, when requested at the post
office
CARD MANAGEMENT HELP DESK
Pathway is committed to providing a quality help desk service to its users, with
formal measurement of activity in order to give a basis for evaluating
performance against agreed service levels.
When cards are issued, an 0800 (free phone) (or 0345 (local call rate)) CMS
help-desk telephone number will be provided to BA customers to report any
lost, stolen or damaged cards. The help-desk will also accept local calls of this
type when they are re-routed from POCL’s seven regional help lines or BA
customer help lines and will cater for non-English speaking customers.
Pathway’s experience is that an ‘0345’ (local call charge) number suffers less
from nuisance and unnecessary calls and we would be pleased to discuss the cost
implications of this during the contract negotiation stage.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 18 of 44
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.4.13.4
4,4.4.13.5
445
4.4.5.1
4.4.5.1.1
4.4.5.2
4.4.5.2.1
4.4.5.2.2
4,4,5.2.3
CMS Help Desk Functions
The functions provided by the CMS help desk include :
¢ Enquiry resolution
* Processing of reports of lost, stolen and damaged cards
* Ordering replacement cards
* Processing of uncollected cards
There will be a voice response system in place to handle calls during and after
manned periods. The help desk will utilise the latest call centre technology,
embracing digital technology, predictive dialling, pacer and multi-lingual voice
response currently in use at Alliance and Leicester. The telephone number will
be promoted in all major telephone directories under a number of headings and
also by a series of poster campaigns in post offices and benefit offices. The
number will be pre-printed on the card to promote awareness.
CARD-BASED BENEFIT PAYMENT PROCESS
INTRODUCTION TO CARD BASED BPS
This section describes in overview the components of the Payment Authorisation
Service (PAS) and the interface to the POCL Strategic Infrastructure. PAS
encompasses that part of the Strategic Infrastructure which specifically deals
with payment distribution and payment encashment at the counter. The section
also describes in detail the components of card-based benefit payment.
PAYMENT AUTHORISATION SERVICE (PAS)
Pathway has taken the overall functions contained within PAS (as defined in the
SSR) and split them into two logical groups. Pathway has defined those
functions concerned with bulk processing and management of payment records
as the Payment Management System (PMS). The functions responsible for
payment of benefits at the counter are part of the POCL Strategic Infrastructure
and are called the counter infrastructure.
PAS has a number of primary functions. These are to :
* Process and manage payments
* Service queries on-line from BA
* Interface with CMS
* Interface with TMS
TMS, as described in Section 4.3.4 provides the interface between PAS and the
counter infrastructure. It also provides the details of transactions carried out at
the counters to both BA and POCL as appropriate.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 19 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
I
Payment Management System I
I
I :
— Payment
I i Authorisation
poo eT System (PAS)
I Boundary
I Transaction Management Service I
1 I
Counter Interface Service
Fig. 3 - Components of the Payment Authorisation Service (PAS)
Payment Management System (PMS).
4.4.5.2.4 The major functions of PMS are to :
* Accept individually authorised payments from the Customer Accounting and
Payment System (CAPS) prior to the due date for encashment
* Merge the payment stream from CAPS with information from the card
management system
* Transmit payment information to TMS for onward distribution to the
counter infrastructure
* Provide a single, complete information source for a customer’s payment
« Record payment encashment and notify CAPS
* Record expiry of payments as notified from the counter infrastructure and
notify CAPS
* Process payment and card stop notices
* Process payment enquiries from CAPS
* Provide the data to support reconciliation
44,5.2.5 Unique to Pathway, A&L has a proven system for recording issue and
encashment of some 100 million girocheque benefit payments per annum and
the provision of reconciliation and accounting services relating to these benefit
payments, This well-established system will form the basis of the Pathway
solution for delivery of PMS. A&L has considerable experience in developing
systems that provide a service to BA and this is best illustrated in the case study
in Annex 6.7 - BA Project.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 20 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.4 - BENEFIT PAYMENT SERVICE
PMS Information Flows
4.4.5,2.6 The overall information flows into and out of PMS are shown in Fig. 4 below.
f -
‘Ms
\ J Card deuals of
NL pare agent
Fig. 4 - PMS Information Flows
4.4.5.2.7_ Pathway’s solution will offer the flexibility to cater for the existing range of
benefits and for the introduction of new benefit types as the BA’s requirements
evolve.
Counter Infrastructure
4.4.5.2.8 The major functions of the counter infrastructure are to :
* Accept individually authorised payments and related card management system
information transmitted through TMS
* Make payments via magnetic card
* Support payment in the case of exceptions such as foreign encashments and
payment by proxy
4.4.5.2.9 Pathway has chosen the Riposte system from An Post/Escher as the basis for
delivery of the POCL Strategic Infrastructure. Riposte provides a secure and
robust electronic delivery to the point of encashment. The counter application
will be based on the existing card-based payment system already in use at An
Post. Details of this system are contained in the case study in Annex 6.12 - An
Post CounterAction.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 21 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
Za
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.5.2.10
4.4.5.2.11
4.4.5,2.12
4.4.5.3
4,.4.5.3.1
The An Post system currently provides the following facilities :
Magnetic swipe card-based payments
Application of payment stops electronically
Application of card stops electronically
Flexible receipting module catering for variable messages
Support for a range of benefit types and the introduction of new benefit types
The system at An Post is also used in conjunction with a household-budgeting
module which allows benefit customers to deduct payments to Utilities directly
from their benefits.
PMS Interfaces
Details of the service interfaces that affect PMS are contained in Section
4,2.12.2, In summary they are :
(a)
PMS to CAPS - This is an external interface which supports file-based
transfer of payment authorisation files to PMS and encashment and expiry
details to CAPS, In addition a transaction-based interface will support
urgent payment authorisations, payment stops and enquiry services.
(b) PMS to CMS - This is an internal interface and provides a formal boundary
(c)
between the payment and card management services. The two functions
supported are :
(i) PMS access to card verification data during the processing of payment
records,
(ii) A transactional interface to enable PMS to be notified by CMS of
updates to payment status following reports of card stops or
monitoring events.
PMS to POCL Strategic Infrastructure - This is an internal interface between
PMS and TMS. TMS in turn then provides a connection to the POCL
counter interface. This interface will support file transfer and real-time
transactions including payment distribution, encashment and expiry details
and emergency payments.
RECEIPT OF AUTHORISED PAYMENTS FROM CAPS
PMS manages receipt of the payments stream and related information from
CAPS. It is critical to control the movement of authorised payment instructions
from CAPS to PMS in a secure manner with demonstrable control over the
integrity of the information. Pathway will implement systems to control this
interface based on best industry security practice and based on the experience of
its
constituent companies, in particular related to :
Reconciliation and accounting of girocheque payments
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 22 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.
BENEFIT PAYMENT SERVICE
4.4.5,.3.2
4,4.5,.3.3
4.4.5.3.4
4.4.5.3.5
4.4.5.4
4.4.5.4.1
* Other existing benefit payment systems
* Management of a similar link to Social Welfare Services in Ireland
Most payment authorisations will be received from CAPS in batch mode over a
secure electronic link or as agreed with BA. The servicing of emergency
payments within the target time of 30 minutes specified in the SSR will require a
more interactive type of interface. Precise details of this interface will be agreed
with BA.
Validation of Payments
Individual record-level validation will be agreed with BA. This will include
checks such as correct identification of the destination post office and
manipulation on an agreed basis of items such as due date in the event that a
post office is closed on the exact date the payment is due. In such a scenario
payments could also be re-directed to a nearby post office.
Enrichment of Payment with Card and Cardholder Details
To support authentication of the card presented at the counter, the payment
record will be enriched by the addition of card security information in order to
match the details of the card presented with the details of the one issued. The
validity is established through a match of the PAN, the CIN, the expiry date and
the Sherman number.
To support verification of the cardholder at the counter, the payment record
will be enriched with personal details selected from those available from CAPS
but not available from the card itself.
DISTRIBUTING DATA TO THE POINT OF ENCASHMENT
To enable a fast response at the counter and to provide a high level of
availability, Pathway will distribute the payment to the customer’s nominated
post office. This does not prohibit collection at an alternative office by the
customer or an agent appointed by the customer. The process of distributing
payment information has been described in detail in Sections 4.3.4.6.17 to
4,3.4.6.18. Briefly, the key process is as follows and as presented graphically in
Fig. 5:
(1) The payment file is received from CAPS
(2) The file is validated, enriched with CMS verification data and collated by
post office
(3) The files are digitally signed and prepared for dispatch
(4) Files can be encrypted if necessary
(5) Files are distributed to the correspondence layer
(6) Correspondence servers distribute files to the post offices
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 23 of 44
OJEC Notice 94/$ 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.5.4.2
4.4.5.4.3
4.4.5.4.4
4.4.5.4.5
Tatiod Tt age Sue
Giorie Reh See
Fig. 5 - File Distribution from Payment Management System to Counter Infrastructure
Resilience to failure
Distributing payment information to post offices provides a far greater degree of
availability than that available through the use of a central system and also
means that payments can still be made in the event of severe network failure.
Pathway anticipates that post offices will hold payment details that are up to two
days in advance of their due date. The Pathway solution will allow post offices
to continue to pay benefits throughout this period in the event of any loss of
central or network service.
Sections 4.3.4.6.20 to 4.3.4.6.25 also describes the process of unassisted
recovery in the case of equipment failure. ‘
Validity of IOP
Pathway recognises the interest expressed by BA in reducing the validity of an
IOP from thirteen weeks to four or five weeks. Pathway would support this
initiative on the grounds that the majority of benefits are encashed within a
short time of their due date. A shorter period of IOP validity would improve
the accuracy of benefit reconciliation for BA and would make a positive
contribution to improved cash management for POCL. A shorter IOP validity
would also reduce opportunities for fraud.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 24 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.5.5
44.5.5.1
4.4.5.5.2
4.4.5.5.3
4.4.5,5.4
4.4.5.5.5
4.4.5.5.6
4.4.5.5.7
4.4.5.6
4.4.5.6.1
APPLYING PAYMENT AND CARD STOPS
Application of Payment Stops
When PMS receives a stop-payment instruction from CAPS it will check its
central payment database for the status of the payment. If the payment has been
encashed no further action is required and CAPS is notified.
If reference to the PMS indicates payment has not yet been encashed, the
counter infrastructure is interrogated to establish whether encashment has taken
place since the last update to PMS. If the payment has been encashed no further
action is required and CAPS is notified.
If the payment has not been encashed then a stop notice is transmitted to the
nominated office and CAPS is notified.
Once a stop is placed and accepted by PMS, Pathway assumes the financial
liability of payment. To support this Pathway will agree service levels for stop
placements with BA.
Card Stops or Alert Instructions
Whenever a card-stop instruction is received from CMS, the central payments
database is checked to determine whether there are any uncashed payments at
post offices for the given card number. If such payments exist, notification is
passed to the counter infrastructure that the card has been stopped and payment
on that card must be denied.
Whenever a card alert message is received from CMS, the central payment
database is referenced to determine whether any uncashed payments exist for
the given card number. If such payments exist, notification is passed to the
counter which will set an alert flag. Any encashments utilising the offending
card are advised immediately to PMS for onward routing to CAPS.
Customer education regarding the card stop process will be provided as part of
the information supplied when cards are issued.
CARD AUTHENTICATION AND CARDHOLDER VERIFICATION
When the card is presented at the post office the card is swiped and
authenticated. The purpose of authentication is to ensure that a valid card has
been presented. The authentication process includes :
* Comparison of the PAN, CIN and Sherman number held on the payment
record to those obtained from swiping the card
* Validation against the electronic list of card stops
* Visual check of the card by counter staff for evidence of tampering or
attempted forgery
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 25 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.5.6.2
4.4.5.6.3
4.4.5.6.4
4.4.5.7
4.4.5.7.1
4.4.5.7.2
If one or more valid payment records exist, the following formal counter
process will take place :
* Print the receipt showing statutory declarations
* The customer is asked to sign the receipt
* The signature on the card and receipt are compared
* If the signature is valid the customer is paid and given a copy of the receipt
* A copy of the signed receipt is retained by the post office counter staff
To support verification, additional information is available from CAPS and
distributed as part of the payment record to the counter staff. They will have
the option to request and record additional independent means of customer
verification.
At present Pathway is not recommending the use of PINs or biometrics as our
research (see Section 4.4.7 and Annex 8) has shown that these additional forms
of verification are unacceptable to the benefit customer base. However Pathway
will consider using biometrics selectively in discussion with BA for selected
segments of the customer base. Biometrics in this case could include use of a
photograph or digitised signature. Pathway is also investigating some of the
recent developments in computerised facial and digital recognition.
IDENTIFICATION OF BENEFITS PAYABLE
Presenting and swiping the card will display on-screen details of all payments
due. The counter staff will also have available to them details of any payments
in the system that are not yet due. Where several payments are due, customers
will be able to request payment of one or more complete benefits but not part of
a benefit. Customers can choose benefits from the list, provided they encash
due payments in ascending order of date within benefit type. We will produce a
receipt of all chosen payments.
An example of a typical benefit payment screen is shown in Fig. 6 overleaf.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 26 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 27 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
4.4.5.8 RECEIPTS
4.4.5.8.1 Each card-based payment will be accompanied by a receipt. The customer will
sign the receipt with the appropriate declaration printed on it. The receipting
function is an application within the POCL Strategic Infrastructure. This
module can be configured to print typical transaction information as well as
information that can be dynamically changed from day to day.
4.4.5.8.2 The standard receipt information will include :
* Date
¢ Time
* Post office
* Counter clerk
¢ Benefit Details
* Declarations
° Messages
4.4.5.8.3 This dynamic information can be incorporated at different levels, including
special messages at the benefit level, messages by due date and specific messages
to individual customers.
4.4.5.8.4 An example of a receipt showing these message types is shown in Fig. 7.
Department of Social Welfare
UNEMPLOYMENT BENEFIT
‘Node: TRAIN2
DATE: 26/05/1995
TIME: 12:14
Name: JOE GIBBONS
RSTNo: 000068110
Pay Period: 04/05/1995 to 10/05/1995
Pay No: A0306563
[Net Amount Due: 65.70
Payments Deductions
Flat: 61.00 Tax:
PRB: 1470 ESB: 5.00
PHON: 5.
‘TOTAL AMOUNT PAYABLE: 65.70
Thave received the sum shown above
to which Iam entitled.
Signs,
26/0571995
I Next Signing Day: Thursday 11/05/1995,
I
ewan!
Fig. 7 - Typical Receipt
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 28 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.5.8.5 The receipt can be either a single copy which is printed twice or a carbonless
two-ply paper receipt. In either case the signed receipt is retained by the post
office counter staff, Pathway is examining the optimum receipting strategy and
equipment and the decision will be based on factors such as :
* Cost of equipment
* Customer acceptance
* Potential use of equipment for other purposes
¢ Integrated printing options
¢ Physical characteristics of equipment
¢ Durability of receipt, legislation and retrieval requirements
4.4.5.8.6 The top copy of the receipt will be stored initially at the post office. Pathway is
willing to discuss the provision of a Value Added Service for long-term storage
and retrieval of receipts.
4.4.5.8.7 Subject to such a service and associated service levels for receipts being agreed,
Pathway will store the receipts and offer a retrieval service. The post office
would forward the receipts in a pouch each week. The receipts would be in
time sequence for each counter position. Pathway would store the pouches and
would determine which pouch(es) to retrieve in support of a given enquiry, by
determining the week and post office of encashment from the activity records
archived within TMS.
4.4.5.8.8 Pathway will continue to consider the appropriateness of image processing and
automated retrieval of receipts but this is currently considered to be
inappropriate because :
* The receipts are not suitable for high-speed reading and imaging
* The enquiry rate is unlikely to justify the cost of capture and electronic
storage
* The use of image in a legal context is still subject to debate
* The cost of paper storage and retrieval would still be incurred as a back up to
the imaged records
4.4.5.9 STATEMENTS
44.5.9.1 Pathway will provide a facility at the counter to enable post office clerks to
order statements on behalf of customers. All such requests will be collated by
TMS and transmitted to BA.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 29 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.5.10
4.4.5.10.1
4.4.5.10.2
4.4.5.10.3
4.4.5.10.4
4.4.5.10.5
4.4,5.10.6
EXCEPTION PROCESSING
Foreign Encashments
Authorisation of payment is normally local to the counter infrastructure, with
payment details being retrieved from the distributed payment files. In a small
number of cases (between 5% and 10%) the customer will be requesting
payment away from their nominated post office.
In this case an on-line request will be generated and a communications link
established with the central location. This on-line request is received by the
correspondence server which passes the message to a software agent. This in
turn processes the request and returns a response to the originating post office.
In this scenario the payment is marked as paid at the nominated post office
preventing any further attempted encashments.
Emergency Payments - Existing Cardholder
In the situation where the benefit customer is a cardholder, the NINO is used as
part of the payment information input by BA staff. The payment will be routed
through PMS and distributed to the nominated post office through the Strategic
Infrastructure and on to the counter infrastructure. Customers will use their
card to collect payment at the nominated office. Normal cardholder
authentication/verification will take place.
Emergency Payments - Non-cardholder
Temporary tokens will be used for processing urgent payments where the
benefit customer does not have a benefit card. The temporary token will be a
single-use device. If appropriate BA staff could also generate a new card request
at this time. The payment will be delivered rapidly from the authorisation in
CAPS to the presentation at the nominated post office of encashment. Issue of
temporary cards is discussed in Section 4.4.4.9 - ‘Temporary Cards to support
emergency payments’.
On encashment of the payment for which the temporary card was issued, the
counter infrastructure will record the use and de-activation of the card for later
notification to CMS. No further payments can be unlocked by this card. The
card will be retained by the post office counter staff.
Card authentication, cardholder verification and receipting will be the same as
for a normal card, subject to the input of appropriate information at the benefit
office in the emergency situation.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 30 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ae
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.5.10.7
4.4.5.10.8
4,4.5.10.9
4.4.5.10.10
4,.4.5.10.11
4.45.11
4.4,5.11.1
Agents and Appointees
Pathway understands the difficulties associated with the management of casual,
temporary and permanent agents and appointees. In the light of automation
and the introduction of cards, there is an opportunity to introduce some changes
in the rules and the business process for dealing with proxy payments. These
will need to be agreed with BA to minimise the risk of fraud. The risk is
particularly prevalent in relation to casual agents. Changes that could be
considered in this area include :
* Use of a paper form to activate a casual payment which could be distributed
with the card or welcome pack
* Insistence that casual agents must possess their own benefit card
¢ Allowing the customer to nominate one or more possible casual agents when
they sign on for a benefit at the benefit office
Invalidation and Suspension of Cards by BA
Pathway will provide a facility that allows BA to invalidate and suspend cards
within the system. Under these circumstances, on receipt of details from BA,
Pathway will immediately place a permanent stop for invalidated cards and a
temporary stop for suspended cards. This change will be relayed from CMS to
PAS in real time. The system will store sufficient details to ensure that a
complete audit trail is maintained.
On presentation of an invalidated card at a post office, Pathway proposes the
following procedures :
* The counter staff swipe the card through the card reader
* The system displays a message requesting the counter staff to retain the card
* The counter staff refers the customer to local benefit office
¢ The system updates CMS to record card pick up
* The card is cut into two at the post office and returned to the CMS help desk
This is a recognised procedure currently in operation throughout the financial
sector.
On presentation of a suspended card, Pathway proposes a procedure similar to
that for invalidated cards, except that the card will be retained by the customer
and by implication the card status will not be amended to record pick up.
NOTIFICATION OF ENCASHMENT AND EXPIRY TO CAPS
Complete details of the encashment and the expiry of payments is returned to
CAPS. The information collected by the counter infrastructure is at a very fine
level of detail. As an example, An Post collect the following details :
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 31 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
@
BENEFIT PAYMENT SERVICE
4.4.5.12
4.4.5.12.1
4.4.5.12.2
4.4.5.13
4.4.5.13.1
4.4.5,13.2
4.4.5.13.3
4.4.5.13.4
<Message:<Group:GROF3050><Node:POST1> <Id:1><Num:38210><Date:23-Jun1995>
<Time:08:57:39> <User:ANNE> <Debit:6100> <Application:Postdraft> <TranDate:23-Jan-1995>
<Data:<PaymentNumber:B9232765><NINO:5146317654> <RecipientName:JOHN LANDIS>
<TranT ype:Cashed> <RecciptsPrinted:1 > <OcrData: <Date:3050><AcctNo:00029873952.>
<Amount:6100><TranCode:98034> > <File:PAY00146.TXT >> <CRC:5395E710>>
NOTIFICATION OF EXCEPTIONAL CARD USAGE
Instances of foreign encashment are identified and transmitted to PMS where a
profile of each payee’s behaviour is maintained.
Where a payment is made by manual keying of the card details, due to a
problem with the card, notification of the exception will be passed to the card
management system so that a profile of such payments can be maintained, with a
view to triggering a replacement card.
AUDIT TRAILS
Counter Infrastructure
The Riposte system from An Post/Escher is used to take payment information
and deliver it to the counter infrastructure. The features of Riposte are
described in Section 4.3.4. In summary, every payment and details of every
encashment are transmitted (and returned) in a secure fashion from PMS to the
counter infrastructure. The POCL Strategic Infrastructure captures all system
events in addition to transaction details. The audit trail will include login by
counter staff and both automatic and manual logoff by counter staff. These
events are stored as journal messages and can be used to prove correct operation
of the system for fraud investigations.
Non-user system messages relating to the network and failure of peripherals are
also automatically logged as journal messages. Each transaction will include
information about the post office, the counter staff, the counter position, date,
time and full transaction encashment information. All transaction, system and
user messages will be stored within TMS on the correspondence servers.
The details of all card- and payment-stop instructions will also be stored in
TMS. These will be archived from time to time but will allow the construction
of a full audit trail for the transaction.
Card Management Service
Events, including cardholder set-up, maintenance of cardholder details and
modification to card status will be date- and time-stamped and recorded to
provide an audit trail of activity. The process or person instigating the event
will be identified on the event record.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 32 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.5.13.5
4.4.5.14
4.4.5.14.1
4,4,5,14.2
4.4.5.14.3
4.4.5.15
44.5151
4.4,5.15,.2
4.4.5.15.3
44.5154
Payment Management Service
All events such as the receipt of payment from CAPS, payment stop activity and
the notification to CAPS of encashment or expiry will be date- and time-
stamped and recorded, to provide an audit trail of activity. The process or
person instigating the event will be identified on the event record. The payment
receipt audit record will also include any available details that identify the given
CAPS transmission.
BENEFIT AGENCY ENQUIRIES
Pathway will make provision for a real time link between CAPS and PMS to
support payment status enquiries from the Benefit Agency. Such enquiries can
also be addressed via the help desk.
An enquiry about payment status, (required to determine whether a stop can be
set), will be automatically actioned on receipt of the payment stop notice and
will trigger an acknowledgement of ability/inability to place the stop. A
payment stop and the associated enquiry can also be applied by the help desk
subject to the receipt of an auditable authorisation for such action.
Pathway will make provision for a real time link between CAPS and the card
management system. BA enquiries relating to the status of a card can also be
addressed via the help desk.
SECURITY
CMS and PMS will be protected by Tandem’s Safeguard security subsystem
which is an extension to the Guardian operating environment and provides
more comprehensive security features. The Safeguard subsystem secures access
to objects such as disks, sub-volumes, files and executable processes. This
security is delivered by maintaining and referencing a database of objects, users
and the explicit authorisations linking the two.
Security of data and its transmission through the network is provided by TMS.
The facilities available through Riposte are described in Section 4.3.4.
In summary these include :
* Application of Cyclic Redundancy Checks at the record level
¢ Application of digital signatures at the file level
* Encryption of files if necessary
The counter-system security uses the above facilities and includes application-
level access control and the Windows NT security services.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 33 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.5.16
4.4.5.16.1
4.4.5.16.2
4.4.5.16.3
4.4.5.16.4
4.4.5.16.5
4.4.5.16.6
4,4.5.16.7
4.4.5,16.8
4,4.5,.16.9
COUNTERFEIT CARDS
Pathway is aware that an operation of this scale will attract fraudsters who
attempt to counterfeit cards. This will generate the following situations where
cards presented are not genuine :
(a) Counterfeit cards which are not on the system
(b) Copies of real cards which are on the system
The opportunities for fraud will be reduced by controls applied at different
levels in the end-to-end process.
System Level Controls
* The nominated office is held only on the system
¢ There is a unique Sherman value for each card
* Cardholder verification information is held on the system
Card Production Controls
¢ A high level of security in the production process
* Use of a ‘deep’ hologram embedded within the card
* Use of electronic etching of the account number on the signature strip
* A high quality of production process and card materials
Counter Procedure Controls
* Visual examination of cards for signs of tampering
¢ Ahigh quality of BA card will ease detection of counterfeits
If a counterfeit card is read and not known to the system, counter staff will
impound the card. The card will be cut into two and returned to the CMS help
desk with supporting information for fraud investigation.
Where a counterfeit card is read and is known to the system, detailed counter
procedures will be followed including card scrutiny, card authentication and
verification of the individual.
In the unlikely event that the customer successfully passes these checks, in the
worse circumstance the card will unlock outstanding payments. This will create
an exception condition when the real customer attempts to cash expected
outstanding payments. If this happens, Pathway will place a stop on the existing
card and generate a replacement card for the true cardholder which will contain
a new security value.
The fraudulent card will no longer pass the authentication procedure at the
counter and will be picked up if used again.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 34 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4,.4.5.17
4.4.5.17.1
4.4.5.17.2
4.4.5,17.3
4.4.5.17.4
44.5.17.5
4.4.5.17.6
RECONCILIATION
Pathway will meet the reconciliation needs of BA by building upon the
automated and manual processes developed jointly by BA and Girobank for
girocheque payments and by utilising the control and reporting facilities
inherent in the An Post system.
The Girobank Reconciliation Service for girocheque benefit payments has been
operating since November 1992. In its original form, it replicated the report set
established over many years in the Benefit Agency. It has subsequently been
extended in a joint exercise involving Girobank, BA and their accountants, Price
Waterhouse. The extended set of accounting reports has delivered an effective
bridge between the calendar-based reporting and those reports which are based
upon Cash Account Weeks.
Currently, BA reconciliation entries come from Girobank’s analyses of issued
and encashed payments
In total, the girocheque BA Reconciliation delivers more than fifty reports
showing issued payments, encashed payments, uncashed payments, void
payments and accounting adjustments. The data is analysed as required (by post
office, calendar period, Cash Account Week, or benefit code) and is delivered in
paper or electronic form to BA internal users and to the National Audit Office.
Key elements of the reconciliation service offered to POCL and BA are :
Post Office Claims Versus Encashed Items
Currently, one of the key reconciliations is concerned with proving that the
cumulative value of post office claims for payments made in a Cash Account
Week is equal to the actual value of authorised items encashed. This
reconciliation is achieved by balancing each post office. Pathway’s shareholder,
Girobank, is currently involved in this reconciliation.
Pathway considers this reconciliation a pre-requisite to settlement for each
period of processing and will deliver proof of the reconciliation of post office
claims to encashments notified to CAPS by the following steps :
(a) Derive the value of each post office claim for encashed automated payments
from the post office log maintained by PAS and reconcile this with the
actual cash position at the post office.
(b) Reconcile each encashment notification to prove that the value of
encashments delivered through PAS equals the issued value held within
PMS.
(c) Reconcile the cumulative value of encashment notifications to the
cumulative value of post office claims.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 35 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
Ps
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.5.17.7
4.4.5.17.8
4.4.5.17.9
4.4,5.18
4.4,5.18.1
4,4.5.18.2
4.4.5.18.3
4.4.5.18.4
PAS will be the basis for both the post office claim and the notice of encashment
for CAPS, therefore the existing problems of arithmetic errors in claims and
differences caused by unauthorised payments (fraudulent cheques and payment
foils) will be removed.
Reconciliation of CAPS to PMS
The reconciliation described above addresses the issues of completeness and
integrity of the payment data within the bounds of the Pathway services.
Pathway anticipates that audit requirements will extend to encompass
demonstrable reconciliation of payments data held within Pathway and CAPS.
The cashed and uncashed analyses could provide reconciliation of CAPS and
PMS information. Full reconciliation of CAPS to PMS requires detailed
consideration of the processing schedules to determine any points of consistency
where both systems align in terms of new payments added and payments
encashed. Transactions in the pipeline from CAPS to PMS (newly authorised
payments) and from PMS to CAPS (encashed items) also to impact upon the
viability of such a reconciliation and the way forward is seen as a detailed design
issue.
PHYSICAL ATTRIBUTES OF PAS
Software
Pathway will use ACI’s GENcard to deliver the card management system. The
application utilises open systems technology and relational database design
supported by Structured Query Language. This application is available for
UNIX and Tandem hardware.
PMS will be based on a re-engineering of the current Girobank Girocheque
Payment Management Service using a 4GL.
Hardware
CMS will run on Tandem Computer’s Himalaya platform. The Tandem
platform provides RISC machines allied to fault-tolerant, parallel processing.
The steady state CMS operation will use multiple Tandem processors located at
two geographically separate sites. Inter-site connectivity will be provided using
token ring and routers linked over 2Mb circuits. This configuration will
provide fall-back for CMS contingency.
PMS will also run on the Tandem Himalaya platform to allow a fully integrated
Benefit Payment Service.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 36 of 44
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
ON os r
BENEFIT PAYMENT SERVICE
SECTION 4.
446
4.4.6.1
4.4.6.1.1
4.4.6.2
4.4.6.2.1
4.4.6.3
4.4.6.3.1
4,4.6.3.2
4,4.6.3.3
4,4.6.3.4
THE MIGRATION OF THE BA CARD
PATHWAY’S SMART CARD CAPABILITY
Pathway’s access to smart card technology is provided by DelPhic the joint
venture company formed between De La Rue and Philips. DelPhic has been
specially formed by its parent companies to address the supply of smart card
technology to the UK and Irish markets. Pathway is therefore uniquely
positioned to provide BA/POCL with a combination of skills and resources
drawn from the market leadership positions of DelPhic’s parent companies.
PATHWAY'S SMART CARD PRODUCTION CAPACITY
Pathway will be able to offer BA/POCL access to the plastic card industry’s most
extensive production facilities. De La Rue’s present personalisation capacity is
25 million cards per annum which will be increased to 40 million per annum.
Philips’ production capacity at present is 60 million cards per annum,
PATHWAY’S EXPERIENCE IN SMART CARDS
De La Rue and the relationship with Philips in the area of smart card technology
gives Pathway access to over ten years of experience in the field of industrial
smart card production.
De La Rue has over 60% of the market for financial payment cards in the UK
financial sector. It has the largest commercial personalisation bureau in the UK
and through DelPhic it has already secured major contracts for smart card
personalisation, which include the Mondex project. DelPhic’s capabilities are
illustrated in the case study in Annex 6.15 - CardLink (Ireland).
The exclusive (and patented) technology currently used by Philips to
manufacture smart cards has recently been independently verified by France
Telecom to be of the most reliable currently available. Philips has also been
awarded the contract to develop IEP the first Compatible Electronic Purse for a
French financial organisation.
Over the last 10 years Philips has achieved many ‘world firsts’ in smart cards :
* First to put the DES algorithm in a smart card (PostBank ‘1986)
* First to use a smart card for workstation security (CTR-Nord 1989)
* First to include RSA algorithm in smart card (EDI-ETEBACS 1992)
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 37 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.6.4
4.4.6.4.1
4.4.7
4.4.7.1
44.7.1.1
4.4.7.1.2
PATHWAY SMART CARD REFERENCES
A selection of key references for smart card technology are given below :
(a) Payment Applications
* 25 million smart cards delivered to the French banks based on the B0’
(B zero prime) technology. Philips, jointly with Bull, are in charge of
the BO’ development for French banks
* La Poste (Fra) Development contract for IEP, the first Compatible
Electronic Purse
(b) Security Applications
* Rabo Bank (Holland) - Electronic banking applications for the bank’s
clients (30,000 smart card readers installed, 100,000 DX smart cards
delivered)
(c) Health Applications
¢ Social Security (Fra) - Identification and authentication of patients
200,000 smart cards delivered
¢ Health Program (Germany) - Identification and authentication of
patients. Over 4 million D2000 cards delivered and the development
of dedicated PE115 terminal smart card reader
CUSTOMER ACCEPTABILITY
INTRODUCTION TO RESEARCH
Pathway has sought to determine the optimal product, positioning and
communications strategy for the BA card from the point of view of benefit
customers, This was achieved by employing qualitative research techniques and
applying them to a representative sample from the BA customer base. The
sample was chosen to reflect socio-demographic type, regional location,
disability, gender and ethnic origin. None of this customer group were opting
for direct credit (ACT). A sample of ‘opinion formers’ was also included. The
complete market research findings are presented in Annex 8 - Research
Programmes.
The qualitative approach has allowed Pathway to investigate and understand the
attitude and views of the sample and to uncover issues in relation to the
transition to card-based payments.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 38 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
iy
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.7.2
4.4.7.2.1
4,.4.7.2.2
4.4.7.3
4.4.7.3.1
4.4.7.3.2
4.4.7.3.3
BACKGROUND ATTITUDES
There is no typical benefit customer but a wide spectrum of individuals with
different types of lives, financial conditions and attitudes towards the provision
of the service. Some may live quiet stable lives, others are in a constant state of
chaos. Some may be careful with their budgets, others live day-to-day and
hand-to-mouth. Some may feel embarrassed, shame or anger about receiving
benefit, others are totally apathetic and accepting. In contrast, many pensioners
tend to resent their pension benefit being called a benefit because they feel it is
an entitlement they have earned. These difference must impact on the choice of
name given to the card, its design and positioning.
Pathway and BA face a reality where a relevant and popular solution may be
difficult to find. Pathway will determine an optimum and customer-sensitive
solution to the problematic issues of card design, name, positioning and
communication by seriously considering the views of the BA customer.
OPINION FORMERS
The opinion formers are people who represent and provide support services to
many benefit recipients. They include Help the Aged, Age Concern RNIB,
MENCAP amongst others. They offer a useful insight into the special needs of
those they serve. They will also prove helpful in the process of rolling out the
benefit payment card and easing its acceptance by the card users.
However, whilst some of them prove to be well in-touch with the views of their
interest groups, the research amongst the customers demonstrated also that
some of the opinion formers offered misleading information. Thus, care must
be taken in the application of their ideas.
The opinion formers were very pleased to be consulted. This goodwill offers us
a good start in the process of building the relationships which may prove to be
critical in helping us launch the card.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 39 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.7.4
4AT7AAL
44.742
4.4.7.5
4.4.7.5.1
4.4.7.5,.2
4.4.7.5.3
ATTITUDES TO BENEFIT COLLECTIONS
The research found that there is a wide spectrum of emotional intensity amongst
BA customers towards many elements of the benefit-collection process. For
example, the use of girocheques, the use of the postal system, entitlement
changes and multiple benefits all produce high levels of anxiety. The underlying
attitudes surface early in the process of claiming benefit. Typically, this is when
signing on, when waiting for the post to deliver the benefit book or when
establishing entitlement, and so on. The anxiety is not apparent at the stage
when the benefit is collected at the post office, which is an experience that
provides re-assurance. Nevertheless, benefit recipients perceive the initial steps
as an integral part of the whole process, so attitudes to the new benefit card
system will be affected by attitudes to other elements of the overall service. A
conclusion of the research is that Pathway and BA will need a partnership and
quality approach to all elements of the process in order that the card-based
payment is well received.
The research also found that benefit recipients do not perceive the current
benefit payment system to be problematic. Indeed, they find it hard to envisage
any alternative being simpler or more efficient than it is now. Some asked, why
change a system that works? We conclude therefore that there is little point in
suggesting to BA customers that the new system is better than the current one in
terms of its simplicity and efficiency. If we do, this may generate a negative
reaction because the message would be unconvincing. Instead, Pathway will
need to position the approach as ‘just as simple to use and no less efficient’, and
use other features to justify replacing the old system. Other important
considerations are BA customer attitude towards safety, security and fraud.
SAFETY, SECURITY & FRAUD
For many, there is a highly charged emotional fear surrounding the anticipation
of the benefit, lest it is lost or delayed. The anxiety is particularly prevalent in
those waiting for their girocheque. This fear arises because of their dependency
on the benefit - some may fear falling into debt while others may already be in
debt and are concerned not to fall in any deeper. Once received, the benefit
provides them with peace-of-mind and re-assurance. Indeed, we welcome the
opportunity of removing the fortnightly anxiety of waiting for the girocheque
and imparting to customers a sense of control.
Customers are also quick to recognise the advantages of a system for reducing
fraud. This is perceived as being an advantage mainly to the Government.
Nevertheless, there are many who strongly approve of fraud reduction on the
basis of not letting people get away with it and an innate hate of waste.
However, customers are also fearful that the card may easily be lost, or that the
computer system will break down and deprive them of money. They need re-
assurance that the system is adequately backed by procedures to cover such
emergencies,
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 40 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.7,.5.4
4.4.7.5.5
4.4.7.6
4.4.7.6.1
4,4.7.6.2
4.4.7.6.3
4.4.7.6.4
4.4.7.6.5
When authentication methods were discussed, customers raised the question of
proxy collections - could they still use an agent? They want this option available.
Nevertheless, their preferred authentication method is the use of a photographic
image of the recipient on the card, and a digitised (hidden) signature system;
these are, of course, expensive solutions. The relatively cheaper alternative of a
visible signature on the card was less popular, but neither was it rejected because
it is perceived as being familiar and easily understood.
Other methods researched were the use of a PIN and biometrics (specifically
fingerprinting). The PIN was the least popular of all methods of authentication.
Fingerprinting was liked by some who thought it very secure but was disliked by
most, who linked it with the negative associations of criminality and Big
Brother, or else they feared it could make proxy collections impossible. In any
case, the technology which this would demand is perceived as being expensive,
‘over the top’ and therefore an unnecessary waste of resource.
RESEARCH RECOMMENDATIONS
We will involve the opinion formers in any further research, so that we
encourage their support for the card solution and develop communications with
BA customers. In any case, they expect to receive information packs in advance
of the launch.
The overall BA/POCL service and procedures will affect how well benefit
recipients accept the new benefit payment card.
The new benefit card should be positioned as being ‘simple and efficient in
operation and use’, not ‘simpler or more efficient’. It should also be positioned
to generate a feeling that it will help fill the recipient’s need for safety and
security, and thus offer them re-assurance.
The main selling point is assumed by the customers to be a reduction of fraud.
This will make acceptance of the card much easier but this rationalisation should
also be combined with the emotional feelings that fraud generates. Such a
combination may serve to build a powerful and persuasive message for justifying
the introduction of the card.
The fears of lost cards or system breakdowns may be countered by
communicating the strengths of the support processes behind the service.
(These will include fast card replacement, the emergency payment system, and
subject to agreement with BA, the ability of customers to receive benefit at their
local post office by providing suitable independent identification.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 41 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.7.6.6 The authorisation process will essentially be a compromise between security
against abuse, being simple enough to operate and being accessible even to
casual agents of benefit recipients. The research concludes that a signature-
based system is the optimal route, especially given the enhanced security of
system-based information which will support customer verification and card
authentication.
4.4.7.6.7 The card name and design should be suggestive of personal security, reassurance
and simplicity. It should be distinctive, highly recognisable, clear and
distinguishable from other BA cards in the household. Above all, it should not
be suggestive of benefit (save for the BA logo) but of its inherent use of
collection or entitlement.
44.8 CONFIGURATION MANAGEMENT
4.4.8.1 INTRODUCTION TO CONFIGURATION MANAGEMENT
44.8.1 A high level of systems availability and a quality service are essential for the
continued confidence of BA and their customers. This will be achieved by
providing a strong, central Pathway Service Management function with all of the
information, training, knowledge and support required to ensure that Pathway
services operate efficiently and effectively.
4.4.8.2 Pathway services and their underlying support services will be administered
centrally by the Pathway Service Management team. This team will provide a
single point of contact for BA and POCL staff.
4.4.8.2 PATHWAY SERVICE MANAGEMENT
4.4.8.2.1 The responsibilities and scope of Pathway Service Management are :
* Help desk services
* Incident and problem management services
* Software support services
« Hardware support services
* Network support services
* Service administration and maintenance services
* Service level achievements
4.4.8.2.2 Pathway, via ICL and Girobank, has extensive experience in the provision of
support services. The ICL Sorbus national help desk supports multi-vendor
systems and software. Girobank currently provides a number of help desk
support functions including :
¢ POCL help desk for Postmaster reconciliation enquiries
* Visa call centre (provided by A&L Personal Financial Services)
¢ IT technical support
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 42 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.8.4
44.8.3.1
4AQ
44.9.1
44.9.2
4.4.9.3
4.4.9.4
4.4.9.5
4.4.9.6
4.4.9.7
4.4.9.8
SECURITY KEY DISTRIBUTION
The public key needs to be distributed to the counter infrastructure in each post
office to enable the checking of the digital signature associated with each
payment file and to verify that the data has not been amended. This distributed
public key has a value aligned with the private key of the Pathway host system.
Pathway will assign the distribution of the public key to Pathway Service
Management as an element of security management. Keys will be distributed
across the network by Riposte.
REQUIRED DEVELOPMENT
The Pathway solution is built upon established and proven components and the
bespoke development is largely limited to changes necessary to tailor those
systems to reflect the format and content of the interfaces with CAPS and to
support additional inter-Service dialogue such as that between PMS and CMS to
enrich given payment records.
The CMS and PMS development programmes have been aligned with the
procurement timetable specified in Chapter 9 of the SSR.
During the Demonstrator Phase the capability of the baseline products from
which CMS and PMS will be developed will be established by reference to those
products in terms of functionality and live use. Modelling of the business
process will be undertaken such that a functional requirement baseline can be
agreed with BA/POCL.
This will allow completion of the design and development of an initial release to
be used as part of the Live Trial.
Details of the above activities which form part of the Pilot Programme are given
in Section 6.
Subsequent to the Pilot Programme CMS and PMS will be developed further to
take account of the results of the Programme and in readiness for integration
and testing of CAPS.
Further information on the post Pilot Programme activities and how they form
part of Pathway’s proposed roll-out plan are given in Section 7.3.
The development process defined above ensures that enhancements can be made
to PMS and CMS as the Pilot Programme proceeds whilst allowing sufficient
time for integration and testing with CAPS prior live usage during :
CMS August 1996
PMS November 1996
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 43 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.4 - BENEFIT PAYMENT SERVICE
4.4.10
4.4.10.1
4.4.10.2
4.4.10.3
4.4.10.4
SUMMARY OF BENEFIT PAYMENT PROPOSAL
Pathway has proposed an end-to-end Benefit Payment Service which is both
low-risk and innovative. The card technology is the widely used magnetic stripe
cards. Pathway’s proposal will be smart-card enabled from day one of
operation. The service can take a known migration path to smart card
technology and is therefore future-proofed.
The central components of the service are based on traditional fault-tolerant
hardware but unique to Pathway, the payment delivery component of the service
is based on a distributed computing model. Distributing payment information
allows rapid authorisation and uninterrupted payment of benefits in adverse
conditions such as network or central systems failure. On-line authorisation of
payments will be required only in the case of exceptions such as foreign
payments.
The transaction details will allow full reconciliation of authorised and encashed
benefits. The receipting system will give the benefit customer full details of
benefits collected and can include personalised messages.
By conducting research on customer acceptance Pathway understands the need
for customer care during transition from paper to cards and will work with BA
to develop innovative programmes to support this transition,
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 44 of 44
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
%, ie
SECTION 4.5 - SPECIFIC RESPONSES
SECTION 4.5 TABLE OF CONTENTS
4.5 SPECIFIC RESPONSES
GENERAL.........
EQUIPMENT CONSIDERATIONS.
BENEFIT PAYMENTS SYSTEM GENERAI
BENEFIT PAYMENTS SHOULD BE MADE TO THE RIGHT PERSON
TOKEN PRODUCTION, ISSUE AND REPLACEMENT:
SECURITY «os.
AUTHENTICATION.
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.5 - SPECIFIC RESPONSES
4.5
C SR4.1
C SR4.2
I SR4.3
SPECIFIC RESPONSES
GENERAL
Can the Service Provider confirm that the service will comply at all times with
all relevant legislation?
Pathway confirms that, as far as it is aware, the service will comply with all
current legislation and it is our intention to comply with all future relevant
legislation. Being UK based, in direct control of the relevant software, and close
to the source of legislative change, Pathway is well positioned to respond to any
such relevant legislative changes.
Can the Service Provider confirm that it will be possible to prove that the
service was operating without defect in evidential support of any appropriate
prosecutions in court?
Pathway confirms that it will be possible to prove operation of the service
without defect in evidential support of any appropriate prosecutions in court.
The service is designed so that a full, auditable history of all operational events
occurring at each counter position and interactions with host application
services is maintained by the system. Initially this will be done on magnetic
storage within the correspondence servers and subsequently archived to optical
media. It will provide information on the operational characteristics of the
system at any point in time, together with the history of all events relating to
transactions passing through the system and their reconciliation. Thus it will be
possible to identify the ‘who, what, why, where and when’ attributes of an event
occurring as a result of business processing and system management activity.
These facilities have already been used to provide evidence to support criminal
prosecutions within the Republic of Ireland.
State how the service will provide the office polling and real time
authorisation; elements of the applications portfolio for value added processing.
Communications with post offices can be initiated in two ways :
* From the centre out to a particular post office
¢ From the particular post office to a central location
The Riposte architecture is a replicated-messaging architecture. In the event that
communications are established with the central location, the systems exchange
state messages and if any state differences are detected then the systems update
each other as necessary. This update can be in the form of replicating
transaction journal messages or transmission of a file (for example a payment
file) to the local post office.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
a Ae
SECTION 4.5 - SPECIFIC RESPONSES
Polling - During the normal operation of the system over a period of a day, the
system will open communications based on the priority of the transaction
message. During the period when the channel is open, an update of all lower
priority transaction messages will take place. In addition to this intermittent
replication of messages to the central location, the end-of-day processing will
initiate communications to the central site to ensure that all remaining
transactions are replicated to the central location. Transactions are collected at
the central location for aggregation, additional Value Added Processing (if
appropriate) and despatch to client systems. Thus the traditional polling cycle is
replaced with an automatic replication of transactions to (or from) the centre on
a time interval governed by the transaction message priority.
This approach has been working successfully at An Post to distribute payment
authorisation files (centre to post office) and collect benefit encashment and bill
payment transactions (post office to centre).
The Pathway implementation plan proposes that the existing POCL Host Data
Polling System be used to collect data from the correspondence servers in the
early stages of roll-out, utilising the existing POCL Value Added Processing
applications to pass data to/from the individual POCL client systems. This
eliminates dependencies on the development of new client interface applications
at the start of roll-out. A strategic ‘bill-payments’ application will be introduced
later in the roll-out programme, which will process transaction data from the
correspondence servers, provide Value Added Processing and interface directly
with the client systems.
Authorisation - The system can support the following real-time authorisation
operations using authorisation data :
(a) Local to the counter infrastructure (in other words, pre-distributed)
(b) Located at a central correspondence server
(c) By including the appropriate access routine, on an external client (acquirer)
system
In the case of benefit payment authorisations, the Pathway design is based upon
local authorisation using pre-distributed payment files as the most cost-effective
and resilient approach where a consistent pattern of encashment exists. The
ability is also provided to support foreign payments, where the authorisation
data is retrieved from the payee's nominated post office or correspondence
server.
Access from the correspondence server to external authorisation services can
also be provided where needed for specific business transactions, such as
transactions involving payment by debit/credit card or queries to a savings
account.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4,5 - SPECIFIC RESPONSES
I SR4,4
I SR4.5
In the situation where the payment cannot be authorised locally then
communication is established with a central location. The message replication
facilities of Riposte are used to generate this on-line authorisation. In this
scenario a high-priority message is generated which opens the communications
to the central locations. This message is received by the correspondence server
and passed to a software agent that processes the request and sends a response
to the originating post office.
All three authorisation approaches are in use within the An Post system; (a) and
(b) for benefit payment authorisations and (c) for savings bank transactions.
Service Providers should indicate their interest in utilising the existing POCL
data capture and document processing services.
Pathway has assumed that a long-term goal of the POCL Strategic Infrastructure
is to eliminate paper handling and hence we have designed our proposed system
to progressively implement this, with electronic capture of transaction data at
the counter. During roll-out and transition to full electronic operation we
would expect, subject to further discussions, to make use of existing POCL data-
capture and document-processing facilities for handling transactions from non-
automated offices. Our architecture for TMS has been designed to enable
transactions captured in this way to be merged with transactions captured
electronically prior to Value Added Processing or despatch to client systems.
Service Providers should state the design methodology (ies) which will be/were
used to produce the software components. They should also indicate the
language/tools used and suggest how small, medium and major enhancements to
software might be incorporated.
Design methodologies - Pathway is using ICL’s Openframework methodology to
control the overall design of the service and the integration of its constituent
components. This methodology is focused on system integration projects and
supports the use of a variety of individual methods and tools within the
individual project stages, under an overall set of control processes, which
comprise :
* Project management, which for this project is based on PRINCE
* Risk management methodology, which is described in Section 8
* Information and change control
At an overall level, Pathway has adopted the architecture developed in the SSR
and is using the following design methodologies :
¢ ADW to model end-to-end process structures and information flows
¢ OPNET to model the overall performance of the system
* Decision Support to model overall service-level characteristics
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
> re
SECTION 4.5 - SPECIFIC RESPONSES
Development Languages & Tools - Pathway has split the systems development
functions into host-based services (supporting CMS, PMS, OSS and VAP) and
the TMS/Counter Interface components, including systems management.
The host-based services PMS, OSS and generic Bill Payments processing (VAP)
will be developed by extension from existing Girobank systems using ADW
methodology and Microfocus Workbench as the lower CASE development tool.
The development of CMS, in the form of extensions to the existing ACI Card
Management package, will be subcontracted to ACI and is based on RDBMS
and SQL.
TMS and counter applications will be developed by extension from the existing
Post Office systems in use at An Post and being prototyped for the Singapore
Post Office (EPOS components). These extensions will use the Riposte
development support environment with Microsoft development and testing
tools using a mixture of Visual Basic and C+ + languages.
System enhancements - these may require development in the counter interface
applications, host-based services, or TMS, as all three components are utilised in
the delivery of end-to-end services. In some cases these will require only
parameter changes in the relevant area (e.g. TMS standing data), in others
software development will be required - either to host-based applications or to
the counter application software. Enhancements to the counter interface will be
achieved normally via re-use and extensions of the existing, generic application
types and will use system management software facilities to distribute
amendments to installed equipment.
Minor enhancements only affect one system component, for example :
(a) Amending the validation of data received from CAPS within the PMS
application.
(b) Altering the user interface component of a counter application (for example
use of alternative GUI ‘widgets’ from the Riposte desktop library).
Medium-scale enhancements are likely to require.a new or extended application
in one area of the system. For example, a new type of bill payment can be
implemented at the counter using different parameters within the generic bill
payment (in-payment) application, but would require separate implementation
of the client interface in the TMS or VAP area, built on one of the generic
application agents (to control the information flow to/from TMS). New
applications of a generic type can typically be implemented within a few weeks
using this approach.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
Cs
SECTION 4.5 - SPECIFIC RESPONSES
I SR4.6
Major amendments would typically require co-ordinated changes, or new
applications, in several areas of the system. An example of this type would be
the introduction of a household budgeting application, which would typically
require interaction with several bill-payment systems and potentially to the
Benefit Payment System. Such amendments would require integration and co-
ordinated testing prior to cut-in to live operation.
Service Providers should state the capacity limitations (minimum and
maximum) of each component of in their proposed service, identifying areas of
overlap between component capabilities.
Counter Interface - There is no inherent limitation in the capacity of the counter
interface imposed by the PC architecture; additional counter positions may be
added as required, along with additional or faster components within the
individual counter PCs, Ultimately the system is constrained by the operational
characteristics of the shared components within a post office such as the office
LAN, communications gateway and disk storage for journal messages and files.
For the equipment proposed these constraints are calculated per post office :
LAN (10Mbps Ethernet) : the maximum transaction replication rate is estimated
to be thousands of transactions per sec and overall LAN performance is limited
to a significantly lower level by PC performance.
ISDN Gateway (64Kbps) : the maximum transaction replication rate to/from any
one correspondence server over the WAN is approx. 30 transactions per second
for a typical transaction mix. Additional ISDN connections can be added at
individual post offices as and when required by traffic patterns.
Hard Disk : the maximum local transaction storage (based on 540Mb disk) is
approx. 2M transactions or 1.3M payment authorisation records or
combinations thereof. For the largest post office, assuming 25 counter
positions, this equates to approximately 150 days transactions of all types or
260 days of benefit payment authorisation records.
TMS - The distributed architecture employed within TMS enables its capacity to
be adapted to meet required transaction loads by increasing or decreasing the
number of correspondence servers supporting the post office branches.
Additional post offices may be added or removed from the service as required.
In addition, the capability of individual correspondence servers may be
extended/decreased by substituting larger/smaller Intel series processors.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 4.5 - SPECIFIC RESPONSES
It is envisaged that initially such servers will be based on dual Pentium
processors with evolution to 2- or 4-way Intel P6 processors. Correspondence
servers based on Pentium processors can support between 1500 and 2000
counters per server depending upon the precise transaction mix and rate, whilst
providing full transaction replication, back-up and recovery facilities. TMS is
configured with disk storage subsystems designed to provide a minimum of
three on-line copies of all transactions, plus benefit payment authorisation files.
Information is expected to be retained on-line for a period of three months
prior to archiving to optical media; this on-line storage capacity can be increased
to a theoretical maximum of several years of transactions by adding additional
disk subsystems (and conversely for scaling downwards is required).
Branch Network - The capacity of the branch communications network is
constrained only by the capacity of the public ISDN service on which it is based,
together with the number of primary rate circuit terminations to effect
connection to the correspondence servers. These are intended to be configured
to support a minimum of 240 concurrent active B channel connections (i.e.
eight primary rate connections) spread over four locations, providing an
estimated 99.9% availability for busy hour call attempts. Additional primary
rate connections can be added (or removed) as justified by changes to traffic
patterns.
PMS - This is essentially a batch file processing and reporting system, whose
capacity can be readily increased by either :
(a) Extending the duration of the payment authorisation processing component
within the overall payment management cycle.
(b) By providing additional parallel processing streams for payment
authorisation processing by splitting the CAPS data stream into multiple
files (for larger scaling, if necessary).
The service as initially configured has a maximum capacity of 20M transactions
(authorisations/encashment reports) within a 12 hour batch window per peak
day. On-line data storage, configured for two months transactions, can be
increased if necessary.
On-line enquiries, emergency payments and stops processing from CAPS
constitute a small percentage of PMS resource demands. These are expected to
amount to several hundred thousand per day, but the system can be scaled to
cope with much larger volumes if necessary.
CMS - This provides a combination of batch and on-line processing facilities to
support the demands of new and replacement card orders and activation, plus
support for help desk operations (lost/found/stolen/etc.) and card
enquiry/control operations from BA staff. The system has been designed to an
expected daily peak capacity of 100K card orders, 20K help desk calls, plus
enquiry/control transactions from BA staff (potential volumes to be discussed).
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.5 - SPECIFIC RESPONSES
I SR4.7
Both batch and on-line processing capacity can be extended in a similar manner
to PMS.
Card Production - The Pathway service assumes the production and
personalisation of approximately 25M cards over a three year period when in
the steady state. Card production can be increased or decreased relatively easily;
personalisation capacity has been based on an average assumed rate of 1.1M per
month, with a maximum of 100K per day, during a smoothed roll-out avoiding
major peaks and troughs. Variations (up or down) in these figures are possible,
subject to contractual discussions on the details of the service roll-out and
appropriate lead-time.
PMS/CMS/Infrastructure Help Desks - The help desk facilities have been based
upon an expected annual total call volume of approx. 3.5M and have been
designed with flexibility in mind; additional (or reduced) capacity can be
provided in relatively small increments as dictated by traffic patterns.
Service Providers should state how potential customer acceptability issues will
be identified and customer acceptability assessed, both prior to roll-out and
once the service is in operation.
Pathway believes that the successful implementation of the new services will be
dependent on the reliability and excellence of the technology being deployed,
and also on its acceptance by potential customers, the associated pressure
groups, and other opinion formers. Accordingly, the need to identify potential
problems and to create understanding and awareness in these groups is vital, and
Pathway’s ability to research, plan, implement, and support a comprehensive
and professional customer education campaign will be key to our success.
Pathway has already undertaken market research (see Annex 8) into potential
customer acceptability issues. Further research will be targeted on potential
customers, consumer groups, and post office staff and will give us an initial feel
for the potential issues which could effect the implementation.
In addition, the corporate members of Pathway have extensive experience and
expertise in implementing automation of this type, and introducing new
products and services to the customers of post offices, both in the United
Kingdom and in the Republic of Ireland. All the knowledge and expertise
gained from this experience will form the basis of a comprehensive potential
issues log which the market research will augment.
Pathway will propose a strategy, an action list, and a timescale for addressing
each of the identified issues to ensure that the implementation goes as smoothly
as possible.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 7 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.5 - SPECIFIC RESPONSES
I SR4.8
The cornerstone of our customer acceptance strategy will be a comprehensive
and professional customer education campaign. Pathway proposes using all
forms of advertising to get understanding and commitment from all target
audiences by communicating relevant messages to all user groups and providing
clear information about how and when the services will benefit and effect them.
Based on experience of customer education exercises of a similar scale and
nature we have identified four key communications objectives to maximise
customer acceptance :
* To educate and inform customers of the simplicity of changeover to the new
services and manage their expectations about the various aspects of the new
services
¢ To inform customers when their specific service will be affected
* To educate and inform opinion formers to overcome possible anxiety relating
to changes affecting the special interest groups they represent and to get them
to become advocates
¢ To educate and inform the general public about the benefits of the new
service and avoid potential opposition and unease about the motives for the
introduction of the new service
To give the most effective distribution of information to all target audiences and
meet these objectives, Pathway’s customer education campaign will advertise the
launch, roll-out, and all other relevant messages using a mix of media, including
an appropriate selection from television, radio, bill-boards, posters, direct mail,
point of sale, and direct response television.
To monitor the success of the customer education campaign, and to learn and
develop the most effective communications throughout the introduction of new
services, Pathway will commission pre- and post-introduction tracking in each
region where a new service is introduced.
In this way we will address the people aspects of the new services and ensure
that they are managed and addressed in the same planned and professional way
as the technical and operational aspects of this implementation.
Service Providers should state the scalability of the service (both up and down)
to allow changes in business volumes to be readily accommodated.
The inherent capacity and scalability of the equipment and service components
proposed has been described in Section 4.5 SR4.6. The distributed approach
adopted within the architecture allows service scalability in relatively small
increments in response to changing business volumes.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 8 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.
PECIFIC RESPONSES
C SR4.9
C SR4.10
C SR4.11
C SR4.12
EQUIPMENT CONSIDERATIONS
The Service Provider is aware of his obligations under the emerging EC
directives on Visual Display Screen Equipment 90/270/EEC and on
Electromagnetic Compatibility (EMC) 89/336/EEC. Can the Service Provider
confirm that all products used in the provision of the service, after
implementation dates, will conform to these standards?
Pathway confirms that products used in the provision of the service will comply
with both 90/270/EEC and 89/336/EEC directives.
ICL, as a principal shareholder within Pathway, operates an extensive in-house
EMC testing facility and has access to all relevant testing procedures to ensure
compliance with these directives.
The standards which come under the scope of Decision 87/95/EEC and of the
Directive 77/62/EEC, will apply to the Services provided under any Contracts
arising from this procurement. Can the Service Provider confirm that all
products used in the provision of the service, after implementation dates, will
conform to these standards?
Pathway confirms that products used in the provision of service will conform to
the standards within the scope of these directives, where such standards are
defined and applicable to the various functions provided within the service. We
note that many existing POCL services and various client interfaces are
implemented using standards which we assume would fall within the scope of
Article 5, Clause 3 of Decision 87/95/EEC, as might innovative aspects of the
service provision in response to the needs of PFI.
Can the Service Provider confirm that any equipment, installed for operation,
will not significantly contribute to the ambient noise level in the office?. As a
guide, the acoustic noise emission of any item of equipment should be less than
60 dB(A), measured at a distance of 1 metre.
Pathway confirms that all equipment installed in the office will be selected so as
not significantly to contribute to the ambient noise level in the office. The
60dB(A) level at 1 metre will be taken as a guide and individual items of counter
or back-office equipment selected to meet this requirement.
Can the Service Provider confirm that all equipment is capability of
withstanding (without degradation in performance) impacts, shock and
vibration, which may occur when in normal use?
Pathway confirms that each item of equipment proposed for use within the post
office environment will withstand without degradation in performance those
impacts, shocks and vibration which may be expected to occur within its normal
use.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 9 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
Cis I Sg
SECTION 4.5 - SPECIFIC RESPONSES
C SR4.13
C SR4.14
C SR4.15
C SR4.16
C SR4.17
Can the Service Provider confirm that any electronic emissions from equipment
will not interfere with other systems in offices?
Pathway confirms that electronic emissions from the equipment proposed within
its service will not interfere with other systems in the office. Equipment
proposed conforms to EN55022, Part B and FCC part 15, subpart B.
Can the Service Provider confirm that provision will be made for logic ground
and mains safety earth to be connected or separated at each counter terminal
supplied and peripheral supplied?
Pathway confirms that provision will be made for logic ground and mains safety
earth to be connected or separated at each counter terminal and peripheral
supplied. This will be part of the site survey/installation component of the roll-
out service.
Can the Service Provider confirm that equipment shall not interfere with the
health, comfort or normal pattern of work of staff as a result of emission of
acoustic noise, vibrations, heat fumes or other radiation, or as a result of its
construction?
Pathway confirms that the proposed equipment will not interfere with the
health, comfort or normal pattern of work of staff as a result of emission of
acoustic noise, vibrations, heat fumes or other radiation, or as a result of its
construction. Equipment proposed conforms to relevant legislation and
standards in these areas, including EN60950 (safety) and ISO 7779 & 9295
(noise level measurement).
The Service Provider to confirm the temperature range which the equipment
can operate in without degradation in performance?
Pathway confirms that all equipment to be installed within the post office
counter and back-office environment will operate without degradation within
the normal office temperature range 10-35 °C.
The Service Provider to confirm the temperature range which the equipment
can withstand without degradation in a storage environment?
Pathway confirms that all proposed equipment can be stored without
degradation in a storage environment within the approximate temperature range
of -5 - 50°C.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 10 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.5 - SPECIFIC RESPONSES
I SR4.18
I SR4.19
BENEFIT PAYMENTS SYSTEM GENERAL
State how the service will prohibit fraudulent attacks (both internal and
external) with particular reference to attempted fraudulent payment
transactions.
In Alliance & Leicester, Pathway has a fraud department at the forefront of
industry developments for fraud control, committed to attacking fraud in a
dynamic and pro-active way and with a proven track record,
The department adopts a ‘managed risk’ approach to achieve its unrivalled
success. Strategies relate to an appropriate mix of fraud prevention, reduction,
control, loss-limitation and investigation following analysis of key fraud
management information.
Specific fraud containment measures within the Pathway proposal include :
¢ The use of a card containing neither payment value nor information relating
to the location for payment collection
¢ Additional safeguards in the process of card collection and activation through
the use of a Card Activation Number
* The use of additional personal verification data at the point of encashment
¢ The use of digitally signed payment authorisation files with full-integrity
checking
¢ The provision of access controls, both physical and logical, and a full audit
trail of all operations within the system. Closed user group facilities within
the ISDN service will be used to restrict network access
* The provision of a full security policy, incorporating control procedures at all
stages of the card order, production and delivery cycle and similarly at all
stages of the payment authorisation validation, distribution and encashment
cycle
BENEFIT PAYMENTS SHOULD BE MADE TO THE RIGHT PERSON
Service providers should state how their proposed receipting procedure would
operate, including details of any additional messages or information which
could be incorporated on the receipt.
Pathway's receipting procedure is controlled by a receipting (software) module
which is parameterised to vary the contents of the receipt for a given group of
transactions, It will also allow the inclusion of messages changed or generated
dynamically.
The standard receipt information will include :
° Date
¢ Time
* post office
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 11 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
fs mf
SECTION 4.5 - SPECIFIC RESPONSES
* Counter staff
¢ Bill payment details/benefit details
* Declaration of entitlement and receipt of benefit
The dynamic information can be incorporated at these three different levels :
By bill/benefit type
¢ By dominant due date
¢ By individual recipient
All of the above dynamic messages are in use by An Post for benefit payments.
The dynamic message formats for Bill Payments are generally implemented by
Bill Type.
In addition to all of the above, the system supports a global message which is
afforded to all receipts. An example of this is ‘The Post Office wishes all of its
customers a very happy and prosperous New Year’.
The information to be incorporated at each of these different levels is provided
to the system through parameter files. The information is distributed to each
post office through the Riposte architecture. Some examples for each of the
three levels are :
(a) By Benefit Type
{i) ‘All recipients of Child Supplement should note that the standard benefit
increases from £30 per month to £40 per month from June 1st 1995’.
(b) By Dominant Due Date
(i) ‘Please note that your next benefit will be paid on Thursday 17th instead
of Friday 18th due to the Bank Holiday.’
(c) By Individual
(i) ‘Please note that your next visit to the Social Services Offices is scheduled
for Monday 12th June 1995.’
The individual receipt capability is also used to give benefit recipients details of
their Household Budget Deductions. This scheme is operated by An Post and
allows recipients to deduct amounts for payment to Utility companies directly
from their benefit payments.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 12 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
y
SECTION 4.5 - SPECIFIC RESPONSES
I SR4.20
I SR4.21
Service Providers should state how and in what circumstances the service will
support and enable payments away from a nominated post office (if
appropriate).
In the steady state operation of the service, the service will support foreign
payments away from a nominated post office in line with the current restrictions
(or other similar procedures to be agreed with the Contracting Authorities).
Following presentation of the payment card, the system checks the local
payment files to ascertain if any payment is due and whether the cardholder
normally collects benefits from this local office. If no records are found the
system initiates a search and retrieval operation through the central
correspondence servers to locate the cardholder’s nominated office and retrieve
any due payment(s), subject to any agreed restrictions on the frequency of
foreign payments. This utilises the on-line authorisation mechanism using high-
priority message replication as described in Section 4.5 SR4.3. To prevent fraud
from multiple encashment, the payment authorisation record(s) at the
nominated office are locked during this retrieval operation and immediately
updated to reflect any encashment(s) paid at the foreign office.
During equipment roll-out there is a potential complexity if a foreign payment
for a card-based benefit type is necessary at a non-automated post office. In
these circumstances a manual authorisation and recording of the transaction
would be necessary. The Pathway proposals on roll-out and application phasing
are based on the principle that equipment roll-out will be complete before cut-
over of the first electronic benefit payments, using the card as the instrument of
payment.
Service Providers should state how they intend to support and enable customer
changes of nominated post office (if appropriate) and how the DSS will be
informed of such changes.
Pathway will provide a facility for a payee to amend the nominated office for
payment on submission of their card. Use of this facility by a given payee can be
inhibited by the Benefit Agency and the post office counter clerk will be
expected to perform card authentication and verification of ownership as part of
the process. Pathway will route the notification of change of office to CAPS.
At the design stage, Pathway and BA will agree whether the change is applied
directly to CMS or whether, to maintain referential integrity of data, CMS is
updated on receipt of a change to personal details from CAPS.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 13 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
Gp y
SECTION 4.5 - SPECIFIC RESPONSES
TOKEN PRODUCTION, ISSUE AND REPLACEMENT
CSR4.22 Can the Service Provider confirm that any card produced, or used by him, in
the provision of the service will conform to all relevant British, European or
International ISO (or equivalent) standards?
De La Rue, the UK’s largest producer of magnetic stripe cards, and Philips TRT
(De La Rue’s partner in DelPhic), one of Europe’s largest producers of smart
cards, both meet the standards of the following national and international
organisations for the manufacture and personalisation of plastic cards.
Visa Card manufacture and personalisation
Master Card - manufacture and personalisation
APACS - manufacture and personalisation of cheque
guarantee
(Association of Payment and Clearing Services)
HMSO - Cleared to Security Level B
ICCC - manufacture and personalisation
(Irish Cheque Card Committee)
GCB - manufacture of plastic card for chip insertion
(Groupement Carte Bancaire - France)
Eurocheque - manufacture and personalisation of cheque
guarantee card
Pathway will supply only card products that conform to the latest international
and ISO specifications.
(a) International Standards Organisation (magnetic stripe cards) :
ISO 7810 Identification cards - physical characteristics
ISO 7811 Recording techniques for information on
identification cards
ISO 7811/1 Embossing
ISO 7811/2 Magnetic stripe
ISO 7811/3 Location of embossed characters on ID -1 cards
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 14 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.5 - SPECIFIC RESPONSES
ISO 7811/4 Location of read-only magnetic tracks - Track 1 and
2
ISO 7811/5 Location of read-write magnetic track - Track 3
Allocating international issue identification numbers
ISO 7812 (IINs) for use on identification cards
ISO 7813 Design and use of identification cards as financial
transaction cards
ISO 4909 Design and use of bank cards with a magnetic stripe
that employ track 3
(b) International Standards Organisation (smart cards) :
ISO 7816 Design and use of identification cards with
integrated circuits with contacts
ISO 7816/1 Physical characteristics
ISO 7816/2 Contact locations and minimum size
ISO 7816/3 Transmission protocols between card and
terminal
ISO 7816/4 Inter-industry commands for data change
I SR4.23 Service Providers should state the maximum time for the production of a card
and its delivery.
The Pathway approach to card production and delivery is described in Sections
4.4.4.4 and 4.4.4.5. Pathway proposes that the card production and delivery
process should work to the following parameters :
Production -
(a) Routine card renewals - despatched 15 working days from receipt of data.
(b) Production of new and replacement of lost & stolen cards - 24 hour
turnaround.
(c) An emergency service to be provided for a maximum of 2% of cards - 12
hours from receipt of data to despatch.
Delivery -
The Pathway approach to card production and delivery is described in Sections
4.4.4.5 and 4.4.4.6. Routine despatches to major offices will be based on 24 hr
delivery; for small offices it may be more sensible to batch together several days
deliveries to minimise handling. Category (b) and (c) deliveries are expected to
be based on next day delivery to all offices.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 15 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.5 - SPECIFIC RESPONSES
I SR4.24
The Service Provider should state how they intend to issue cards to authorised
customers.
Card Supply
Pathway will deliver the inactive card to the nominated post office and deliver a
pick up notice (PUN) to the customer. Only the PUN will contain the code
necessary to enable activation of the card for the purpose of benefit collection.
The PUN will not include any visible indication of the customer’s nominated
post office.
The nominated post office will be required to sign for a batch of cards in their
sealed carriers. This process, plus resolution of any queries arising, will be
managed by Pathway.
Card Collection
On presentation of the customer’s PUN, the (inactive) card is read and the Card
Activation Number (CAN) input from the PUN. Following a check that the card
information generates an identical CAN, the customer will sign the card and a
receipt for its issue. The card is then activated to enable collection of authorised
payments either immediately or in the future. An independent means of
customer identification will also be required to support the above process, and it
is also possible to selectively use the customer personal details information,
supplied by CAPS, as a further check.
Where customers are unable to collect cards in person, Pathway proposes, for
discussion, the following additional options :
* Initial advice from BA of a new customer should include the list and
associated personal details of known agents who would be permitted to
collect the customer’s card
¢ Supplementary proof of identity should be presented by such agents at the
time of requesting card activation
* Those agents who hold benefit cards in their own right should present their
own card for verification when collecting a customer’s card
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 16 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
sy
SECTION 4.5 - SPECIFIC RESPONSES
I SR4,25
I SR4.26
SECURITY
The Service Provider should state how he will ensure that all data (electronic or
paper-based and including stored data) is secure against unauthorised access
and that the service is protected against internal fraud and counterfeiting.
The Pathway security policy and IT standards and practices are tailored to the
needs of the system and service being delivered. Appropriate controls - either
physical or data - are included within the system design. The systems developed
meet or exceed the information security requirements set out in BS7799,
covering all aspects of access to electronic and printed data. The Pathway
Security Policy is provided as Annex 5.
The design protects electronic information within the system by the use of
appropriate authentication, access control, audit and information integrity
mechanisms, together with physical controls on the environment. Control
summaries will be used to ensure the operation of access controls and that the
data has referential integrity.
After full service roll-out, paper storage will be confined to copies of benefit
payment receipt counterfoils, issued at the counter. These will be collected,
batched and stored in a secure environment for subsequent investigation and
audit in a similar manner to the existing PDRs.
BA/POCL will have a ‘right to audit’ security aspects of Pathway’s proposed
service at a more detailed level and, during the proposal evaluation phase, we
would expect to disclose, under appropriate conditions of confidentiality, the
individual security methods used within the design.
See also Section 4.5 SR 4.18 and SR4.26.
The Service Provider should state how case sensitivity will be applied in the
service domain (as described in SSR Section 4.3).
Within the solution offered by Pathway, the system will allow for the
identification of sensitive cases, as notified by CAPS, and special procedures will
be introduced which are acceptable to our clients. This procedure will cover all
occurrences of the sensitive data. In particular we would highlight the following
areas :
(a) Access Control at System PMS - CMS.
The solution offered by Pathway will include a security subsystem. Within
the system, access control can be restricted at various levels within the
service. This includes record, screen and data levels.
Where unauthorised access is attempted audit trails are kept and will be
made available.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 17 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ei on
SECTION 4,5 - SPECIFIC RESPONSES
I SR4.27
(b) Access Control within TMS and Counter Infrastructure.
Both services include a security subsystem to deny object access to
unauthorised parties and maintain an audit record of authorised access.
Within the counter interface, user access to the underlying operating system
functions and data files is inhibited. Counter staff only interact with the
Riposte Desktop applications, which will protect sensitive data.
(c) Despatch of Cards and PUN.
Where customers are identified as case sensitive, Pathway will offer
alternative means of controlling the production, delivery and receipt of the
card and PUN.
AUTHENTICATION
The Service Provider should state how authentication data would be collected,
both initially and on a regular or continuing basis.
We assume that this question relates to what we would call cardholder
verification data.
We propose that the Cardholder Verification Method (CVM) to be used initially
is signature. We do not propose to collect this data as such but to rely on the
controls in our proposals for the distribution of both cards and pick up notices
(PUNs).
The proposed approach to card distribution and collection, as described in
Sections 4.4.4.5 and 4.4.4.6, enables the customer’s signature to be captured on
the card in the presence of the counter clerk. The controls within this process,
including the use of the CAN and supporting evidence of identity, will support
the secure collection of signature as the primary CVM.
We realise that the method of signature collection we are proposing has risks
but these risks are well known because this method is used for all financial
institution credit and debit cards at present. .
As part of the benefit payment process, additional customer verification data, as
supplied by CAPS, will be available to the counter clerk to support further
customer proof of identity when appropriate.
Pathway is aware that there will be a migration to other forms of CVM
including the use of smart cards to store, for example, digitised signatures or
photographs or both. We would look to working closely with the Benefit
Agency to agree a practical method for the collection of improved CVM
information. In the interim other technologies, for example laser engraving the
signature onto the card will be considered.
We also believe that there are no practical alternatives to our proposed method
for the initial system if the timescales laid down in the SSR are to be met.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 18 of 19
OJEC Notice 94/S 165-S8937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.5 - SPECIFIC RESPONSES
I SR4.28
The Service Provider should provide any background information and research
that may support their proposed method of authentication.
In January and February 1995 the Research Business conducted Qualitative
Research into ‘A Card for The Benefit Agency’ on behalf of one of the
shareholders of Pathway. The research was conducted via 30 paired depth
interviews with benefit recipients and 10 depth interviews with potential
opinion formers representing many of the minority groups, such as the elderly
and single parents.
The key objective was to investigate the attitudes to a change from the current
paper-based service to a new card-based service, and in particular how various
authentication methods were perceived.
The five options put forward for authentication were :
¢ Signature written on the card by the customer, and then compared with a
signature provided by the customer on a payment receipt
* Signature captured, stored within the card, and then displayed on the screen
at the post office for staff to compare with a signature provided by the
customer on the payment receipt
¢ Photograph on (or in) the card to be compared with the customer at the
counter position
* Personal identification number (PIN) for each card to be remembered by the
customers and then entered on a PIN pad at the counter position
¢ Finger print to be captured and then stored within the card for the counter
computer to compare with the customers’ finger print via a finger print pad at
the counter position
The research indicated that none of the five methods are entirely free from
drawbacks for all potential customer segments. The ideal method needs to
strike a balance between providing enough controls to secure against fraud and
abuse, and being simple enough for all customers, in all customer segments, to
operate (or use without embarrassment).
The most widely accepted methods, throughout all customer segments, were the
signature-based systems, although within specific individual segments other
systems were often first choice.
The message is, if we can implement suitable fraud controls in a signature-based
system, this will be generally well received across all customer segments. If it is
appropriate to migrate to a different authentication method in the future then
we will have to be careful about which customer segments we approach first,
and we should be prepared for a more complex education programme and an
extended bedding-down period.
The full research report is included as Annex 8.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 19 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 4.6 - VERIFICATION OF BA & POCL FUNCTIONAL OBJECTIVES
SECTION 4.6 TABLE OF CONTENTS
4.6 VERIFICATION OF BA AND POCL FUNCTIONAL OBJECTIVES.........0:+s00+0
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 4.6 - VERIFICATION OF BA & POCL FUNCTIONAL OBJECTIVES
4.6
VERIFICATION OF BA AND POCL FUNCTIONAL OBJECTIVES
This section acts as a verification that the functional requirements of both BA
and POCL have been adequately addressed in our response to the SSR. The
verification is presented as two tables looking at the objectives of both BA and
POCL.
Table 4.6.1 - Verification check against BA functional objectives
BA Objectives : Pathway Response : See
Section :
a I provide a method of The proposed solution is built on
payment which ensures I proven components and services 4.2.5
payment of the right designed to provide an efficient and I and
money, to the right secure end-to-end payment process. 4.4
person at the right Payment and associated data is held
time; in multiple locations within the
process to ensure its availability but
I most importantly in the customer’s
nominated post office. This enables
positive authorisation of the correct
payment, to the right person at the
right time
b I provide a fully secure Pathway has proposed a highly secure
system that eliminates I system which has a complete audit 4.3.4.8
fraud as far as possible I trail for every transaction together
and controls residual with access controls, digital signatures
liabilities; and CRCs. The end-to-end process is
resistant to fraud and provides
detailed information to support fraud
investigations when required
c I provide improved The Pathway solution captures the
systems to detect and complete encashment details and 4.3.4.6
monitor unauthorised _I prints a receipt for signature by the and
activity and supply customer. The archiving system will I 4.4.5.13
evidence to support retain encashment details and an audit
prosecution of illegal trail of all transactions to support
action; prosecutions
d I provide full accounting I The solution proposed by Pathway
and reconciliation collects transaction information ata I 4.4.5.17
facilities; very fine level of detail. Full
reconciliation and accounting will be
supported by the proposed solution.
Transaction details are gathered for
all normal counter functions and all
exceptions such as transaction
reversals
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 6
OJEC Notice 94/S 165-58937/EN
Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.6 - VERIFICATION OF BA & POCL FUNCTIONAL OBJECTIVES
OJEC Notice 94/S 165-58937/EN
BA Objectives : Pathway Response : See
Section :
reduce current The use of industry-standard
administration costs, components and the nature of the 4.2.3
secure the lowest value I distributed messaging architecture and
for money cost for the I ensures a cost-effective solution. The I 4.4.2
provision of the new ability to introduce new benefit
service and provide for I services quickly and without
continuous disruption to existing benefit services
I improvement in value _I will ensure a continued improvement
for money throughout I in value for money. By enabling the
the period of the capture of all information required
contract(s); for, and resulting from, benefit
payments, paper will be eliminated
and the overall efficiency of the
process improved
provide an efficient The counter solution proposed by
customer service which I Pathway is in full operational use by I 4.2.3.3
is accepted and the post office and the Social Welfare I and
understood by them, Service in the Republic of Ireland. 4.3.5.2
BA staff and POCL The system has proved to be highly
agents and staff; acceptable to customers, it has
reduced transaction times and is used
by a wide variety of staff
provide flexibility to The solution proposed is based on
cope readily with any sets of generic functionality and is 4.3.3
future changes affecting I highly parameterised to facilitate new I and
benefits or customer benefits and changes to existing ones. I 4.4.6
base and to adapt to The solution has a clear migration
developing needs of path for the move to smart cards and
customer service, allows security to be progressively
accounting or security; I upgraded as the need arises
be consistent with the I The Pathway solution is consistent
Government’s aim of with the Government aim of 4.2.3
encouraging the use of I providing a cost-effective, efficient
automated credit option for payment at a post office
transfer (ACT) ona while not affecting the existing ACT
voluntary basis while option
continuing to provide
the option of payment
at a post office for
those who prefer it;
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 6
Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.6 - VERIFICATION OF BA & POCL FUNCTIONAL
BA Objectives : Pathway Response : See
Section :
i I enable all of a person’s I Benefit customers will activate all
I benefit entitlement(s) to I benefits due with a single card. A 4.4.5.7
be paid in one receipt will be produced detailing the
transaction using a benefits received, the respective
single token or card for I amounts, suitable messages and
the identification of all I declarations
benefits;
j I ensure that any token I The solution proposed by Pathway
or card identification will be smart-card enabled at roll-out I 4.4.6
system can migrate to a I to the first office. The card migration I and
multi-purpose smart strategy proposed will enable BAto I Annex 9
card; take advantage of increased levels of
card utility as the technology matures
k I encourage the use of The NINO is the prime reference
the National Insurance I number within the Pathway solution. I 4.4.4.4.3
Number (NINO) as the I The NINO will be the primary
prime reference number I reference number on the cards, where
for communications it is included within the Primary
between the BA and its I Account Number. It will be embossed
customers, their on the card, electronically etched on
employers, or other the card signature strip and coded
Government Agencies; I onto the magnetic stripe. Customers
will be encouraged to use their NINO
in all communications with BA and
when contacting the Pathway help
desk
1 I use IT systems that are I Robust and proven, each service
robust, as far as component is based on established 4.2.5,
possible already technology widely in use. Pathway 4.4.5.18
proven, and secure has established a security policy and I and
against fraud, all systems will incorporate 4.3.7
unauthorised access and I appropriate authentication, access
disasters, are capable of I control, integrity and audit
development and mechanisms. All central systems are
interface with existing I duplicated over geographically
systems, separate sites. POCL counter
operations are not dependent upon
the immediate availability of the
network or central services,
minimising the impact of failure of
any component of the solution. The
solution design is modular and
incorporates generic building blocks
using industry-standard components
and development tools
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 6
OJEC Notice 94/S 165-58937/EN
Date: 08/06/95
FUJ00098232
FUJ00098232
Lae
SECTION 4.6 - VERIFICATION OF BA & POCL F
'UNCTIONAL OBJECTIV!
Table 4.6.2 - Verification check against POCL functional objectives
POCL Objectives
Pathway Response
See
Section +
to provide continued
customer choice of
services available at post
offices and be acceptable
to customers;
Pathway is proposing an intuitive
counter interface which is proven to be
acceptable to both counter clerks and
the public. It already supports a
significant number of automated
business products directly relevant to
POCL and the generic approach
proposed by Pathway facilitates fast and
non-disruptive development for new
business products
4.2.3.5
and
4.4.7
to retain and strengthen
POCL’s clear branding
links with its customers;
The solution proposed has proven to be
non-intrusive in the interaction between
counter staff and customers It improves
the quality of interaction and related
customer service. The look and feel is
fully customisable to allow POCL to
present its preferred image
4.2.3.3
I to maintain POCL’s
customer base;
The infrastructure proposed will enable
POCL to strengthen its links with
customers by improving customer
service and transaction times. POCL’s
links with the customer base will be
improved by offering additional services
4.2.3.3
to support government
policy of a nationwide
network of post offices;
The infrastructure will support the
network by linking all post offices in a
seamless equally capable and non-
discriminatory fashion. The service
improvements provided by Pathway will
help significantly in sustaining the
existing Post Office network
4.2.3.3
4.3.7.3
to be capable of
introduction in all post
offices;
The solution proposed is capable of
introduction to all post offices. Pathway
is also proposing alternative counter
equipment which can be offered as an
option for smaller, lower transaction
offices
4.2.9.1
Pathway Response to
COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN
Page: 4 of 6
Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 4.6 - VERIFICATION OF BA & POCL FUNCTIONAL OBJECTIVES
POCL Objectives Pathway Response See
Section :
f I to retain and enhance The Pathway solution offers the ability
POCL’s commercial and I to capture full details of all business 1.7
financial integrity; transactions at the counter. This allows I and
full automated reconciliation of all 4.3.6
business activities and the electronic
provision of data required by
Operational Support Systems
g I to improve overall Pathway offers a paperless system with a
efficiency and cost common interface and full 4.3.3
effectiveness for POCL I reconciliation which will improve the and
and its clients; overall efficiency and cost effectiveness I 4.4.2
for POCL and its clients
h I to support and help Pathway has proposed additional
agents in the business opportunities that are relevant I 8.3.3.3
development of their to all post offices. The use of industry-
private business; standard components, enables the use of
the counter systems proposed in direct
support of agents’ non-post office
business subject to an appropriate
business case and controls to maintain
security and prevent fraud
i I to be acceptable to staff I The Pathway counter interface has
and agents; proved to be very acceptable to staff and I 4.2.3.4
agents where it is in use on ALPS and in I and
Ireland 4.3.5
j I to facilitate automation I The solution proposed will capture all
of other areas of POCL I details of automated counter 4.3.4.10
infrastructure, e.g. transactions which will support and
accounting and provide data for automation of other
distribution, and areas of the POCL infrastructure and
support wider business I provide comprehensive management
information needs; information
k I to retain and gain new I The Pathway solution offers fast
business by improving I implementation of new services and 4.2.3.3
quality of service to all I accurate delivery, accounting and and
clients; reconciliation essential for improving 4.3.4.10
quality of service
1 I to provide the flexibility I The flexible, easy-to-use interface and
to meet a diverse range I the inbuilt parameterised approach will I 4.3.3
of existing and potential I support the needs of existing and
client needs and potential clients. As an organisation
applications; Pathway has a unique blend of skills to
support POCL in strengthening links
with clients
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 6
OJEC Notice 94/S 165-58937/EN
Date: 08/06/95
FUJ00098232
FUJ00098232
i
SECTION 4.6 - VERIFICATION OF BA & POCL F
‘Gh
'UNCTIONAL OBJECTIVES
POCL Objectives Pathway Response See
Section :
to provide long-term The Pathway solution will provide
stability for the Post stability for the Post Office network by I 1.2
Office network as a providing a secure benefit delivery
retail outlet for benefit I system and by enabling the introduction
payments; of new benefits quickly without
disrupting existing services
to adopt a flexible and I The overall design makes extensive use
efficient approach to IT I of industry-standard components and 4.3.3,
systems and adhere to interfaces. The use of standard PC 4.3.5.4,
industry standards so as_I technology, Microsoft software and the I 4.3.7.3
to secure the benefits of I message replication architecture within I and
developments in IT and I TMS and the counter infrastructure, SR 4.22
retail sectors, thereby offers value for money and the ability to
achieving value for rapidly exploit future technology within
money and faster the IT, retail and financial sectors
delivery of new
products and services;
to retain customers’ Pathway will work with POCL to
trust in the integrity of I develop a set of communications which I 4.2.3.5
POCL and improve the I will reinforce the safety, security and and
quality of service to efficiency aspects of doing business with I 4.4.7
customers; the Post Office. The solution will enable
counter staff to deliver service
confidently
to facilitate the The Pathway solution includes a card
provision of added management system and a counter 4.4.2.2
value services, e.g. card I infrastructure capable of taking on a and
and/or token issue and _I variety of cards or tokens 4.4.3
management, that will
enhance POCL’s service
offering;
to ensure the migration I The Pathway roll-out strategy has been
of appropriate carefully planned to handle the 4.2.5.5
automated systems migration of appropriate automated and
without any reduction I systems without any reduction in service I 4.4.6
in service levels; levels
to be a key enabler in The solution proposed is designed to be
helping improve flexible. It will give POCL an 4.3.4.10
POCL’s opportunity to offer additional services
competitiveness, in in line with client needs thereby
meeting its business improving the relationship with clients
partners’ needs, and and presenting the opportunity for
enhancing future developing new business
business viability.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 6
OJEC Notice 94/S 165-58937/EN
Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - S$
SECTIONS TABLE OF CONTENTS
5 STEADY STATE SERVICES ..
5.1 INTRODUCTION «....:sereeseeee
5.1.4 STRUCTURE OF SECTION 5.
5.1.2 APPROACH TO SERVICE DEVELOPMENT AND INTRODUCTIO!
5.1.3 SERVICE DELIVERY ORGANISATION ..
5.2 THE POCL STRATEGIC INFRASTRUCTURE
5.2.1 INTRODUCTION ..
5.2.2 SERVICE DEVELOPMENT AND INTRODUCTION
5.2.3 STRATEGIC INFRASTRUCTURE SERVICE OPERATION FROM THE USER PERSPECTIVE
5.2.4 SERVICE PERFORMANCE...
5.2.5 BAYPOCL RESPONSIBILITIES
5.3 BENEFIT PAYMENT SERVICE
5.3.1 INTRODUCTION .
5.3.2 SERVICE DEVELO!
5.3.3 BPS OPERATION FROM THE USER PERSPECTIVE
5.3.4 SERVICE PERFORMANCE....
5.3.5 BA/POCL RESPONSIBILITIES
5.4 SUPPORT SERVICES.
5.4.1 INTRODUCTION ....
5.4.2 HELP DESK CALL RECEPTION AND CALL TRACKING
5.4.3 SPECIALIST HELP DESKS.........
5.4.4 UNDERLYING SUPPORT SERVICES.
5.4.5 USER PERSPECTIVE.
5.4.6 PERFORMANCE.......
5.4.7 CONTRACTING AUTHORITIES RESPONSIBILITIES.
5.5 POTENTIAL DISASTER SCENARIOS ...
5.5.1 INTRODUCTION .....sseseseseterereeee
5.5.2 COUNTER SYSTEM FAILURE (X1 & X2).
5.5.3 TMS SYSTEM FAILURE (X3) ......
5.5.4 BPS SYSTEM FAILURE (X4 & X5)
5.5.5 NETWORK FAILURE (X6 & X7) ...
5.6 CONTRACT MANAGEMENT SERVICE
5.6.4 INTRODUCTION AND OVERALL APPROACH .
5.6.2 SCOPE OF THE CONTRACT MANAGEMENT FUNCTION
5.6.3 A VIEW FROM THE USER'S PERSPECTIVE,
5.7 CONTRACT TRANSFER SERVICE
5.7.1 OVERVIEW....sccseseseeeeeeseseneaee
5.7.2 PARAMETERS FOR CONTRACT TRANSFER
5.8 SPECIFIC RESPONSES.
OanrrRERE
Ni
~~
RSBBRSEHSRERGBES oe oH
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.1.4
SAA
5.1.1.2
5.1.1.3
5.1.1.4
5.1.1.5
5.1.2
5.1.2.1
STEADY STATE SERVICES
INTRODUCTION
This section describes Pathway’s approach to providing ‘business as usual’ or
‘steady state’ services both during and after roll-out. It confirms that Pathway
will meet the service performance criteria required and provides an explanation
of the Pathway approach to service management.
STRUCTURE OF SECTION 5
The operational services Transaction Management Service (TMS), Operational
Support Service (OSS) and the Counter Interface are described in the context of
their application and performance within the POCL Strategic Infrastructure
Service in Section 5.2. Card Management Service (CMS) and Payment
Management Service (PMS) are described in the context of the Benefit Payment
Service in Section 5.3 and the Support Services, (including the underlying
support services), are described in Section 5.4.
Sections 5.2 to 5.4 each make reference to Pathway’s generic approach to
service development and introduction, described in Section 5.1.1, and identify
where specific differences to this approach have been adopted.
Several potential disaster scenarios are presented in Section 5.5 showing how
various services would be affected and how Pathway’s service administration
team co-ordinates activities to restore service operation back to normal.
Contract Management is described in Section 5.6 and Contract Transfer is
described in Section 5.7.
Examples demonstrating Pathway’s service capability are presented in the text
and references are made to case studies in Annex 6 where more detailed
descriptions are documented.
APPROACH TO SERVICE DEVELOPMENT AND INTRODUCTION
The diagram in Fig. 1, shows the generic approach Pathway has adopted for the
selection and development of steady state services.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ry
SECTION 5S - STEADY STATE SERVICES
5.1.2.2
5.1.2.3
5.1.2.4
Selectappropriate I ‘The service is selected from appropriate existing services
service of Pathway’s shareholders and principal subcontractors
Compare service I Develop service specification
against BAPOCL I until it meets the precise
requirements requirements of the SSR
es No Specify service
Doves it march ? ee modifications to
a achieve mazch
ves
nd
I Document new service
I processes & procedures
Le Operational processes and procedures for BAIPOCL
and Pathway staff for normal service, fallback and
recovery operation
Build new service
environment and
support infrastructure
Hes
Test service operation
Test and, if necessary, modify service
components during demonstration phase
<e Ske
=e
Implement service pilot
nd monitor performan
Fig. 1 - Pathway’s Generic Approach to Service Development
This approach will result in services that exactly match the requirements detailed
in the SSR and which are founded on practical experience. They will be
reviewed jointly with BA/POCL during the pilot phase. Each service will be
supported by documented processes and procedures and by Pathway staff who
are fully trained and experienced in its operation. They will have been
developed to the stage where only minor modifications may be necessary to
accommodate enhancements requested by BA/POCL as a result of experiencing
live running during the pilot phase.
Pathway will place the majority of its supply agreements for steady state services
directly with its shareholders and its principal subcontractors. The overriding
factors influencing this decision are their capabilities, expertise and track record
in delivering similar services over many years. Through Pathway, BA/POCL will
be able to exploit these strengths and take advantage of strong, stable,
established organisations and infrastructures and so minimise any risks.
Fig. 2 shows Pathway’s service structure and the service suppliers.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
Ba =) (Foc “sernse\ I
\ Manager” Manager” —/
NO L-
Client
B
[systems
; Payment ae!
[Opera ational
Ga AV easier 9 wick van = I
- _ > ManagementI . /
(Benefit 7% I Service \
iG a ay PN —~
“ “ecco
oN \. Clients
(“Benet VO \ \ leas
\ customers i, oN
oe (ost Office Postmaster
0 Post Office
\ Customers /
Fig. 2 - Pathway’s Service Structure and the Service Suppliers
I These services : Will be supplied by :
I Operational Services
Benefit Payment Service
Card production & distribution De La Rue
CMS Alliance & Leicester
PMS Girobank
POCL Strategic Infrastructure services
TMS ICL, Girobank
Counter Interface ICL
OSS Girobank
Support Services
Pathway Call Reception Centre
Help desks Pathway
Benefit Payment Service (CMS & PMS) Girobank
POCL Strategic Infrastructure Service (TMS, I ICL, Girobank & BT
Counter Interface, OSS)
Underlying support services (HW,SW, ICL, Girobank, BT
Network and applications) & An Post
Contract Management Service Pathway
Contract Transfer Service Pathway
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
y
SECTION $5 - STEADY STATE SERVICES
5.1.3
5.1.3.1
5.1.3.2
5.1.3.3
5.1.3.4
SERVICE DELIVERY ORGANISATION
Within the organisational framework of Pathway’s Operations Directorate,
shown in Fig. 3, each service will be managed by a dedicated service manager
supported by a core team. This team will be involved from the outset in
creating and modifying existing documentation and training materials required
to meet the needs of BA/POCL and Pathway.
LJ
Oper
I Service Manager -I
eee
I (Benefit Payment)
(POCL Strategic Infrastructure)
[Cl & TMS Si
L CMS & PMS Support foo C1 8 TMS Support
OSS Support
i Service Manager
\ (Help Desks)
Service Manager
ervice Administration)
i
~Pathway Call Reception Centre I» Configuration Management
CMS Help Desk E Change Control
PMS Help Desk ~ SLA Management
—Technical Help Desks Contract Support
Fig. 3 - Pathway’s Operations Directorate - Organisation Structure & Responsibilities
During the pilot phase, all aspects of staff training and service operation will be
tested thoroughly. Additional staff will then be appointed and trained in
readiness to support an increase in workload during the roll-out phase and as
BA/POCL staff undergo the learning process.
During steady state, service managers will be responsible for the efficient
operation of their services, their service suppliers and subcontractors, the
maintenance of quality standards and their performance against agreed service
levels.
A service administration team will be appointed under a senior manager
reporting directly to the operations director. The team will be responsible for
the overall contract management and efficient running of the day-to-day quality,
operation and change management of all of Pathway’s systems and services.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 54
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.1.3.5
5.2
5.2.1
5.2.1.1
5.2.1.2
5.2.1.3
5.2.1.4
5.2.1.5
5.2.1.6
5.2.1.7
Pathway’s Operations Directorate will provide a single point of contact for the
communication and review of all steady state services. Regular reviews will be
held according to a jointly agreed structured format to discuss all aspects of
service performance and operational quality. This is addressed in more detail in
Section 5.6.2.
THE POCL STRATEGIC INFRASTRUCTURE
INTRODUCTION
Pathway’s POCL Strategic Infrastructure Service will provide an accurate and
reliable end-to-end service from the counter interface and the ‘back-office’ to
POCL client systems. It will provide a resilient, fully automated transaction
capture, reconciliation and POCL client system interface in a secure and robust
environment.
The main components of the Strategic Infrastructure Service are the Counter
Interface, TMS and OSS.
The counter interface is the prime interface for POCL staff through which they
may access Pathway on-line services. It will provide real time authentication,
authorisation and recording of benefit payments and benefit payment cards,
(described in Section 5.3) and all of the functionality required for POCL counter
transactions to replace ESNS, ECCO+ and the APT Bill Payment system.
TMS provides a fault-tolerant and highly secure messaging environment for
routing transactions between the counter, back-office applications, POCL
central systems and POCL client systems.
OSS will initially provide Outlet Remuneration & Reconciliation and Reporting
& MIS functions, however its modular architecture will enable the introduction
of additional operational support services when required.
Pathway has selected the most appropriate hardware platforms and network
communications system that meet the specification required and which will
support the current ESNS, ECCO+ and the APT Bill Payment system.
Pathway’s modular architecture provides cost-effective support for additional
applications and a range of upgrade options which will accommodate
BA/POCL’s current and future expansion requirements.
Through its shareholders and principal subcontractors, Pathway has access to
many years of experience in the field of hardware/software supply, development
and systems integration together with the provision of reconciliation and
reporting services.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ron
SECTION 5 - STEADY STATE SERVICES
5.2.2.1
5.2.2.2
5.2.2.3
5.2.2.4
5.2.2.5
5.2.2.6
5.2.2.7
SERVICE DEVELOPMENT AND INTRODUCTION
All the components of the Strategic Infrastructure Service will be developed and
introduced using the generic approach described in Section 5.1.1.
Pathway has selected ICL to provide the hardware behind the Strategic
Infrastructure Service and An Post/Escher to provide the counter interface, TMS
and the TMS messaging environment based upon Riposte software. This
software is reliable, secure and resilient with a proven track record of being used
successfully throughout 400 of the largest post offices in Ireland and by the
POCL ALPS-ESNS project. (See Annex 6,12.)
The hardware and peripherals of the Strategic Infrastructure Service will be
supplied by Pathway using the skills and experience of ICL which is one of the
largest and most successful computer companies in the UK. ICL is currently
installing the equipment for the ALPS project running ESNS. (See Annex 6.5.)
Girobank has been chosen to develop and manage OSS. Through Girobank,
Pathway has secured expertise in providing management information and
reconciliation services. They have a proven track record of accurately providing
a full issue and encashment reconciliation of 100 million benefit payments per
annum. (See Annex 6.7.)
The branch network will be provided by BT, and its design is based on detailed
consideration of the location of post offices and their projected transaction
volumes.
The development of the Strategic Infrastructure Service will be based upon
existing operational procedures and products. The Riposte Human Computer
Interface will be agreed during the demonstration phase and will be tailored to
meet POCL’s requirements following discussion, simulation and measurement of
transaction volumes. Further refinements will be identified and introduced
during the pilot phase and tested prior to roll-out. (See Section 7.)
The Strategic Infrastructure Service will satisfy the requirements of POCL
because :
(a) It provides an environment where all transaction data is automatically
backed-up providing security against data loss and rapid automatic recovery
in the event of system failure.
(b) It supports a wide range of transaction types with many different
requirements for storage and onward transmission of data to client systems.
(c) It provides full reconciliation of the POCL Cash Account and Postmaster
remuneration calculations. The daily reconciliation process is described in
SRS.19.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.2.3
5.2.3.1
5.2.3.2
5.2.3.3
5.2.3.4
5.2.3.5
5.2.3.6
(d) It provides comprehensive reports and management information necessary
for transaction trend analysis and the measurement of the performance of
individual post offices.
(e) It provides a user interface and software that are friendly and intuitive. This
results in reduced training overheads, enthusiastic users and an early
delivery of business benefit.
(f) It is modular and flexible and will enable new applications and functionality
to be incorporated with minimum disruption and cost.
STRATEGIC INFRASTRUCTURE SERVICE OPERATION FROM THE USER
PERSPECTIVE
In larger post offices there is a Postmaster in charge of both counter and back-
office processes. Other staff predominantly serve at the counter. In smaller
post offices the roles of Postmaster and counter staff are merged and so in the
narrative that follows references to either apply to the same person.
Before opening the post office for business, the Postmaster will complete the
start-of-day procedure. This will give a screen-based report showing the value
and breakdown of stock in hand (including cash) carried over from the previous
day. All files will then be open for the input of transactions.
Throughout the day, transactions made at the post office counter are input to
the counter interface using any of the following :
* Bar code reader
* OCR reader
* Magnetic stripe reader
* Smart card reader
* Compact keyboard (or, optionally, a colour touch screen)
The counter clerk will input the method of payment (cash, cheque or other
financial token) and complete the transaction. When required, depending on
transaction type, a receipt will be produced and the customer’s signature
obtained.
The process for benefit payment transactions is described in Section 5.3.3.
Throughout the day, completed transactions are passed to TMS where they are
processed for distribution to POCL client systems or to OSS where they are
stored ready for the process of reconciliation and for the production of
management information reports. This process is transparent to counter staff
and Postmasters.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 7 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.2.3.7
5.2.3.8
5.2.3.9
5.2.3.10
5.2.3,11
5.2.3.12
5.2.4
5.2.4.1
5.2.4.2
5.2.4.3
In a multi-counter post office, the counter interface system backs-up all
transactions in flight to the other counter positions. In single-counter offices,
the system backs-up its transactions to TMS. This ensures that, should any
break in service occur, completed transactions have been saved and can be
recovered automatically. To the user, the back-up process is seamless and
transparent.
When the post office has closed and all transactions have been completed, the
Postmaster will perform his end-of-day procedures. OSS will provide a
reconciliation for the post office and give a full analysis of stock-in-hand
(including cash). Client summaries will be produced automatically.
Each Wednesday, the Postmaster’s end-of-day procedure will initiate the
production of the post office’s weekly Cash Account. (See Annex 3.)
Postmasters remuneration information, reports and management information
will be produced daily by OSS but may be distributed daily or weekly according
to the requirements of POCL. The Postmaster’s reports will be distributed to
the counter interface system at pre-determined times. When required, hard-
copy reports may be obtained locally by the Postmaster using his back-office
printer.
Pathway will install new applications for the counter and back-office systems
when required by POCL. From a user’s perspective, they will be simple
extensions to the menu of automated processes for handling customer
transactions or producing reports, having a consistent interface with which they
are familiar.
To POCL’s customers, the Strategic Infrastructure Service will provide their post
office with a modern, reliable and efficient way of conducting business.
SERVICE PERFORMANCE
Pathway confirms that the POCL Strategic Infrastructure Service will be capable
of meeting the required service performance levels for the counter interface and
TMS and will improve upon the standards and performance criteria currently
applied to existing POCL services.
Availability of the Strategic Infrastructure Service will exceed 99.9% for up to
24 hours per day in accordance with a post office’s operating schedules.
Specific closures for the purpose of Cash Account production and cash
reconciliation will be agreed during the contract negotiation stage.
Pathway’s communications network will consist of multiple data circuits
providing fast, reliable communications between post office counters, POCL
systems and POCL client systems. The availability of this network will exceed
99.9%,
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 8 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.2.4.4
5.2.5.1
5.2.5.2
5.3
5.3.4
5.3.1.1
5.3.1.2
Fig. 4 shows the performance offered by the Strategic Infrastructure Service.
Service transaction times indicate a 10% improvement over the stated BA/POCL
requirements. Additional service performance figures are provided in SRS and
SR6.
Transaction Type Response Service transaction
Retail < 2 seconds < 20 seconds
Bill Payment < 2 seconds < 20 seconds
Benefit Payment (local post office) < 2 seconds < 20 seconds
Benefit Payment (foreign post office) _I < 8 seconds < 25 seconds
Fig. 4 - POCL Strategic Infrastructure Service Performance
BA/POCL RESPONSIBILITIES
To ensure that the counter interface performs to specification it is imperative
that the counter staff and Postmasters adhere strictly to the procedures
documented in the service operations manual. It is important that the following
key points are observed :
(a) All hardware and peripheral devices must be used in accordance with the
specification and procedures.
(b) All faults that are observed must be reported promptly to the Pathway help
desk.
(c) Field engineer access must be allowed whenever required during covered
hours.
TMS will be available 24 hours per day. POCL client systems may impose
constraints on the service if data transfer schedules agreed at the negotiation
stage are not strictly adhered to. Changes to data transfer schedules will be
agreed between Pathway’s service manager and POCL’s service manager.
BENEFIT PAYMENT SERVICE
INTRODUCTION
Pathway’s Benefit Payment Service (BPS) will provide a consistent end-to-end
service from the service boundary interface with CAPS through to counter staff
at the post office and back to CAPS. It will allow BA to provide customer
details and payment information and enable POCL to pay the right customer the
right payment at the right place at the right time.
The main components of BPS, as stated in the SSR, are the Payment
Authorisation Service (PAS) and the CMS.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 9 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.3.1.3
5.3.1.4
5.3.1.5
5.3.2
5.3.2.1
5.3.2.2
5.3.2.3
5.3.2.4
5.3.2.5
5.3.2.6
As explained in Section 4, Pathway has taken the overall functions contained
within PAS and split them into two groups. Functions concerned with the bulk
processing and management of payment records are defined as PMS. Those
functions which are responsible for the payment of benefits at the counter are
part of the POCL Strategic Infrastructure, which is described in Section 5.2.
CMS provides for the manufacture, supply and personalisation of new and
replacement cards and will process the invalidation of lost and stolen cards,
while PMS provides for the authorisation of due payments and the recording of
all encashment details.
Through its shareholders De La Rue and Girobank, Pathway is able to draw
upon many years of experience in the fields of card technology, secure card
production, card personalisation, card distribution, transaction authorisation
systems and fraud prevention.
SERVICE DEVELOPMENT AND INTRODUCTION
Both CMS and PMS will be developed and introduced using the generic
approach described in Section 5.1.1.
Pathway has selected Girobank’s card management service to provide the basis
for CMS with De La Rue providing card production, personalisation and
distribution. CMS uses a card management system from Applied
Communications Incorporated (ACI). ACI Supports more than 400 customers
operating over 900 systems in more than 50 countries worldwide.
PMS will be developed by Girobank, whose existing transaction reconciliation
system programmes for the processing of girocheque issue and encashment will
be tailored to meet BA/POCL requirements. This well-established system has
been proven through the reconciliation of approximately 100 million benefit
payments per annum. (See Annex 6.7.)
Pathway will also draw upon the experience of An Post who provided the
software for the conversion of benefit payments. issued by the Department of
Social Welfare in Ireland (See Annex 6.12).
In adapting these solutions, Pathway will establish CMS and PMS as separate
services running on fault-tolerant multiprocessor systems in two secure locations
which are geographically remote.
BPS will be integrated fully with the POCL Strategic Infrastructure Service
described in Section 5.2. It will satisfy the requirements of BA/POCL by
ensuring that :
(a) Cards will be distributed securely to post offices and activated only on the
presentation of a valid pick up notice (PUN) by a customer whose identity
has been verified.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 10 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION S$ - STEADY STATE SERVICES
5.3.3
5.3.3.1
5.3.3.2
5.3.3.3
5.3.3.4
5.3.3.5
5.3.3.6
(b) Personal details, appropriate to the use of the card will be held securely on
the system and used to verify customers’ identities and authorise payments.
(c) The timing, value and location of all automated benefit payments will be
known and the delivery of benefit payments will be guaranteed.
(d) The opportunity for fraudulent encashment of benefit payments will be
minimised by adopting high security card technology and data encryption
techniques.
(e) All benefit payment data will be automatically backed-up providing security
against system or data loss and rapid automatic recovery in the event of
failure.
(f) BA staff will have on-line access for the interrogation of benefit payment
status and the issue of stop notices and emergency payments.
(g) A secure, reliable data transfer interface to CAPS will be provided.
BPS OPERATION FROM THE USER PERSPECTIVE
On receipt of instructions from BA staff and CAPS, CMS will arrange for the
personalisation of cards and their delivery to the appropriate post offices.
Barcoded batches of inactive cards will be delivered to post offices in sealed
envelopes. The Postmaster signs for these and reads the bar code into the
system to confirm to CMS that the batch of cards has been safely received. The
cards must be stored securely in the post office.
A PUN will be delivered to the home address of the customer informing him
that his benefit payment card may be collected from his nominated post office
and giving instructions on how to provide proof of identity.
To collect his card from the post office, the customer must present his PUN
together with at least one further proof of identity such as a current passport,
driving licence or public utility bill. This process will be discussed and finalised
during the contract negotiation stage.
The post office counter clerk will retrieve the card from store, swipe it through
the magnetic card reader and input the card activation number (printed on the
PUN) to the counter system. The system will respond with either confirmation
that the PUN is valid or that it is not. In the latter case the customer will be
advised to contact his nearest benefit office.
Having confirmation of a valid PUN, the counter clerk will ask the customer to
sign both the card and a receipt. The card is then activated for the encashment
of due payments.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 11 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.3.3.7
5.3.3.8
5.3.3.9
5.3.3.10
5.3.3.11
5.3.3.12
5.3.3.13
5.3.3.14
CAPS will transfer details of new customers’ entitlements and benefit payments
to BPS 48 hours in advance of the due payment date. PMS will distribute this
information to post offices, via TMS. Invalid data will be rejected at this stage
and CAPS notified. Notification of card status is supplied to PMS from CMS.
To receive payment, the customer must present his valid card at a post office.
He may request a statement of all outstanding due payments and select some or
all for payment. Only sequential, whole, due payments will be allowed.
The counter clerk will swipe the card to input its details into the system. If the
card is valid, the system will respond with details of outstanding due payments
and some personal details such as address and date of birth which may be used
as additional verification of the customer’s identity. If the card is not valid, the
system will respond with instructions to the counter clerk to take specific actions
agreed between Pathway, BA and POCL.
If a counter clerk has any undue concerns regarding the identity of a customer
or the validity of his benefit payment he will be able to seek assistance from the
PMS help desk, described in Section 5.4.
If a customer loses his card or if it is stolen he must contact the CMS help desk
immediately. The help desk staff will invalidate the current card on the counter
interface and on PMS so that it may no longer be used for benefit payment
encashment at any post office. The help desk will also arrange for the issue of a
replacement card and PUN. The CMS help desk is described in Section 5.4.
Details of encashments will be returned to CAPS daily from PMS. On time
expiry, any authorised payment which has not been encashed will be made void
at the counter interface and in PMS, with confirmation being returned to CAPS.
Transaction data of card issues, benefit payment encashments and expiries will
be used for reconciliation, audit and MIS reports.
BA staff will be able to access the system via CAPS to make general enquiries
and monitor information. Typically this will include :
* Placing stops on cards and payments
* Enquiring on the status of cards and payments
* Arranging for emergency payments
Optionally Pathway will provide BA staff with benefit payment encashment
details for individual customers by date, post office, value and benefit type. This
may assist in dealing with overpayments and customer complaints of
underpayment. BPS will also provide a full audit trail of all benefit payment
encashments which may be used to assist in the detection and investigation of
fraud.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 12 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION S$ - STEADY STATE SERVICES
5.3.4 SERVICE PERFORMANCE
5.3.4.1 Pathway confirms that the Benefit Payment Service will be capable of meeting
the required service performance levels for CMS and PMS and, integral with the
POCL Strategic Infrastructure Service, will improve upon the standards and
performance criteria currently applied to existing benefit payments.
5.3.4.2 BPS availability will exceed 99.9% for up to 24 covered hours per day in
accordance with BA/POCL system operating schedules. The CMS help desk will
provide a 24 hours per day, 365 days per year service for the notification of lost
and stolen cards. Fig. 5 shows the performance offered by BPS. End-to-end
service transaction times indicate at least 10% improvement over the stated
BA/POCL requirements. Further details are provided in SRS.S5 and SRS5.6.
Activity Response Service transaction
Local payment (at counter interface) < 2 seconds < 20 seconds
Foreign payment (at counter interface) I < 8 seconds < 25 seconds
Invalidate lost or stolen card <5 seconds < 30 seconds
Stop notification <5 seconds < 30 seconds
Payment query <5 seconds < 30 seconds
Emergency payment <5 seconds < 30 seconds
Despatch of replacement card 24 hours
Batch issue of cards < 5 working days
Delivery of PUN 2-3 working days
Issue of emergency cards to BA 24 hours
Fig. 5 - Benefit Payment Service Performance
5.3.5 BA/POCL RESPONSIBILITIES
53.5.1 To ensure that CMS and PMS perform to specification, counter staff,
Postmasters and BA staff must adhere strictly to the procedures documented in
the service operations manual.
5.3.5.2 When issuing a new or replacement benefit payment card, the POCL counter
clerk must be satisfied that the identity of the customer is correct and that the
PUN is and at least one further independent means of identification are
provided.
5.3.5.3 When making benefit payments, POCL counter clerks must be satisfied that the
card is valid and must verify the customers identity.
5.3.5.4 In order for the service to operate effectively, it is essential that information
from CAPS about new benefit customers and amendments to existing customers’
data is accurate and timely.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 13 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.4
5.4.1
5.4.1.1
5.4.1.2
5.4.1.3
5.4.2
5.4.2.1
5.4.2.2
5.4.2.3
SUPPORT SERVICES
INTRODUCTION
Pathway will provide end-to-end support for all services. High levels of
support, availability and service quality are essential for the continued
confidence of BA/POCL, clients and customers. As described in Section 5.1.2,
this will be achieved by establishing a strong central Pathway Service
Management team with all of the information, training, knowledge and support
infrastructure required to ensure that Pathway services continue to operate
efficiently and effectively. The Pathway Operations Directorate organisation is
shown in Fig. 3. Indicative staffing levels are provided in SRS.14.
The service managers for the Benefit Payment, POCL Strategic Infrastructure
and help desk services are responsible for their efficient operation and support
in accordance with the service definition. They are also responsible for the
management of any underlying and subcontract services.
The Pathway Service Administration Manager is responsible for monitoring the
day-to-day operational integrity and performance of all Pathway services against
agreed and contracted service levels,
HELP DESK CALL RECEPTION AND CALL TRACKING
Pathway’s help desk will provide the focus for all enquiries or problems and all
calls will be received via the Pathway Call Reception Centre (PCRC).
A direct line help desk telephone number will be provided for customers with
card-based queries, for example, stolen cards. For these calls, the PCRC
exchange will simply monitor and log the number of calls received and re-direct
them to the CMS help desk automatically.
Fig. 6 shows the structure of Pathway’s help desk service.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 14 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.4.2.4
5.4.2.5
5.4.2.6
Direct line for BA customers
® to report lost or stolen benefit payment cards
Current
BA Help Line
ee Current =
® POCL Help Line ~~
Fig, 6 - Pathway’s Help Desk Structure
For calls received from BA/POCL help lines, BA/POCL staff or the ITSA help
desk, the PCRC will automatically record the calling number using computer-
integrated telephone technology. The site of the calling number will be checked
against a database of registered POCL and client sites and the caller’s details will
be logged automatically onto the incident database.
The call will be allocated a reference number on the incident database system
categorising it by caller, service required and priority. This call reference
number is used throughout the life of the enquiry to identify it uniquely. At all
times, progress towards final resolution of the enquiry is monitored
automatically in the incident database as an auditable sequence of date- and
time-stamped events until final resolution of the enquiry is achieved. A call’s
priority is automatically escalated if pre-determined time limits are exceeded.
In many cases, the caller will know which specialist help desk is required.
Pathway will provide either Interactive Voice Response (IVR) or automatic
routing for these calls. With IVR the caller will be given a menu of options and,
using touch-tone dialling, will be able to select the required help desk. With
automatic routing the caller will be provided in advance with a set of help desk
numbers, the last digit of which will determine the call destination. In both
instances, callers will have the option to speak to a PCRC operator if they
prefer.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 15 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
PTS i
SECTION 5 - STEADY STATE SERVICES
5.4.2.7
5.4.2.8
5.4.3
5.4.3.1
5.4.3.2
5.4.3.2.1
5.4.3.2.2
5.4.3.2.3
5.4.3.2.4
5.4.3.3
5.4.3.3.1
5.4.3.4
5.3.3.4.1
If a call is routed to the wrong specialist help desk, it will be re-routed by the
specialist to either its correct destination or to a PCRC operator. The PCRC
incident database will automatically record the new destination and continue to
monitor the call.
PCRC operators will handle calls for which the final destination is unknown
and, where necessary, will refer the call to a specialist help desk described in
Section 5.4.3 or the service administration team described in Section 5.4.4.
SPECIALIST HELP DESKS
INTRODUCTION
Pathway will provide CMS and PMS help desks as well as technical help desks.
CMS HELP DESK
Pathway has chosen Girobank to provide the CMS help desk. Its account
management function has been at the forefront of telephone banking since the
1970s and it offers a 24 hour service, 365 days per year using the latest call
technology. (See Annex 6.8.)
The CMS help desk will receive calls primarily from customers who wish to
report lost or stolen benefit payment cards.
When a lost or stolen card is reported, the CMS help desk will immediately
invalidate the card on CMS, triggering a cascade of events leading to the update
of PMS and the counter interface, preventing any benefit payment encashments
against that card. The help desk will then arrange for the issue of a replacement
card and place its details on PMS and at the nominated post office.
The CMS help desk may also take enquiries from BA/POCL staff or from the
BA/POCL help lines.
PMS HELP DESK
Pathway will provide the PMS help desk through its shareholder Girobank
which, as described above, is able to draw on considerable experience of call
centre operation. Girobank also currently provides a help desk for POCL staff
for Postmaster reconciliation enquiries.
OSS HELP DESK
Pathway will provide an OSS help desk through its shareholder Girobank to
assist in reconciliation reporting queries and other enquiries.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 16 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.4.3.5
5.4.3.5.1
5.4.3.5.2
5.4.3.5.3
5.4.3.6
5.4.3.6.1
5.4.3.6.2
5.4.3.6.3
5.4.3.6.4
5.4.3.7
5.4.3.7.1
TECHNICAL HELP DESK - SOFTWARE
Pathway will provide total support for all operating systems and applications
software through ICL’s System Support Centre, which will provide a first- and
second-line diagnosis function for all supported products.
The System Support Centre has some 500 technical experts with a wide range of
diagnostic tools. Their relationships with major hardware and software vendors
and manufacturers gives them access to all of the necessary technical
information and support including engineering change notices.
The System Support Centre is an authorised Microsoft Service Centre. Its close
working relationship with Microsoft provides Pathway with the latest support
tools, technical information, documentation and training.
TECHNICAL HELP DESK - HARDWARE
Faults will be referred to the hardware help desk which will ensure that
problems are resolved with the minimum of downtime. This may involve
simply giving advice over the telephone, field repair visits or whole unit
replacement of faulty equipment.
Pathway will provide the hardware help desk through ICL Sorbus. To support
the help desk, Pathway will also have access to 320 of ICL’s field engineers UK-
wide, dedicated to supporting PC systems and supported by the ICL System
Support Centre. The PC support operation within the System Support Centre is
manned by over 50 staff, including Microsoft-certified professionals and
Microsoft systems engineers. ICL currently service over 250,000 PCs, including
approximately 100,000 non-ICL PCs, and over 60,000 desktop printers and
peripherals.
Details of proposed call to fix times and escalation levels and procedures are
provided in SRS.16.
Preventative maintenance will be provided by Pathway through the Prevent
Unscheduled Maintenance Activity (PUMA) which was implemented by ICL in
1991. ‘PUMA’ is currently in place on all ICL's major retail customer locations
and large desk-top network sites.
TECHNICAL HELP DESK - NETWORKS
This will provide day-to-day operational control by a central management
function of all the physical network components, including remote fault
diagnosis and the assignment of alternative routes for local and remotely
managed network components.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 17 of $4
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5,4.3.7.2
5,4.3.7.3
5.4.3.7.4
5.4.3.8
5,4,3.8.1
5.4.4
5.4.4.1
5.4.4.2
This will be achieved through the use of HP Open View, a leading network
management tool. Network components will be managed by Simple Network
Management Protocol (SNMP) which is supported by HP Open View and
provides a consistent view of all the components across the entire network.
Pathway will provide a help desk for the maintenance of the wide area network
(WAN) through British Telecom. The system will automatically test each
connection between the central backbone and the individual post offices at pre-
determined intervals according to the type of post office, and will automatically
highlight problems. The system has considerable in-built resilience, such as
alternative addressing, which will be invoked whilst faults are progressed and
cleared. British Telecom has a proven record in maintaining WANs to achieve
very high levels of availability.
HP Open View provides many facilities to ensure the application-level services
are operating correctly. In addition, the Riposte operating environment in TMS
together with facilities built into components such as the ISDN cards, provide
additional and complementary capabilities.
ROLL-OUT HELP DESK
The roll-out help desk provides a single point of contact for all enquiries about
plans and progress of the roll-out programme.
UNDERLYING SUPPORT SERVICES
INTRODUCTION
The underlying support services will be managed by a small highly skilled and
dedicated team reporting directly to the Service Administration Manager.
During steady state, it is anticipated that the workload will require a team of six
but during roll-out when these activities are at their peak, the team will be
doubled in size. The main functions of this team are described below.
CONFIGURATION MANAGEMENT
The service administration team will maintain control of the integrity and
configuration of the system. This will include providing the following services :
* Maintaining records of counter equipment removal/relocation and network
changes
* Software distribution, including automatic installation on individual PCs, and
licence monitoring
* Reference data management
* Reconfiguration of system components and configuration version control
* Remote diagnostics including the ability to control PCs remotely in real time,
monitor critical system data, execute programs or reboot PCs
¢ Systems security management
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 18 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.4.4.3
5.4.4.4
5.4.4.5
5.4.5
5.4.5.1
5.4.5.2
5.4.5.2.1
5.4.5.2.2
5.4.5.2.3
CHANGE CONTROL
Change requests will be logged, verified and passed to the service administration
team which will schedule the changes into the ongoing service development
programme. Change control will be the subject of regular reviews between
BA/POCL and Pathway. These reviews are described in Section 5.6 - Contract
Management Service.
SERVICE LEVEL AGREEMENT MANAGEMENT
The service administration team will ensure that Pathway’s performance in
delivering services, according to Service Level Agreements, is visible through
accurate and meaningful reports. This will include monitoring the performance
of the PCRC and specialist help desks.
CONTRACT SUPPORT
The training and documentation of Pathway’s services will be jointly agreed
between Pathway and BA/POCL. The service administration team will ensure
the successful provision of training, in terms of its scheduling and
implementation, and will be responsible for the distribution of documentation to
BA/POCL staff. The team will also ensure that any customer education and
marketing literature is distributed to the appropriate locations.
USER PERSPECTIVE
INTRODUCTION
Enquiries may be received directly from customers and from BA and POCL
staff.
CUSTOMER ENQUIRIES
BA and POCL staff will be able to answer most of the customer enquiries (such
as : card not received; amount of benefit disputed; benefit claimed more than
once) but if necessary, they may contact Pathway for assistance.
When cards are issued, an 0800 (free phone) or 0345 (local call rate) CMS help
desk telephone number will be provided to BA customers to report any lost,
stolen or damaged cards. The help desk will also accept local calls of this type
when they are re-routed from POCL’s seven regional help lines or BA customer
help lines and will cater for non-English speaking customers. The languages
spoken will include Welsh, Urdu, Hindi, Gujarati and English.
Pathway’s experience is that an 0345 (local call rate) number suffers less from
nuisance and unnecessary calls and we would be pleased to discuss the cost
implications of this during the contract negotiation stage.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 19 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.4.5.3
5.4.5.4
5.4.5.5
5.4.6
5.4.6.1
5.4.6.1.1
5.4.6.1.2
5.4.6.1.3
5.4.6.2
5.4.6.2.1
5.4.6.2.2
BENEFIT AGENCY STAFF ENQUIRIES
Enquiries may be received directly from BA staff, or via the BA help line or ITSA
help desk and service delivery function. Examples of such enquiries include :
details of historic payment transactions; fault reporting; and how to register a
permanent agent. Calls may be directed to the specialist help desk, via the
PCRG, or to the PCRC operator using an 0345 local call rate number.
POCL STAFF ENQUIRIES
Enquiries may be received directly from POCL staff or via POCL’s seven
regional help lines. Examples of such enquiries include : additional validation
checks when concerned about payee validity despite passing normal checks;
fault reporting; and advice on how to change a customer’s nominated post
office. Calls may be directed to the specialist help desk, via the PCRC, or to the
PCRC operator using an 0345 local call rate number.
BA/POCL SERVICE MANAGER ENQUIRIES
During the contract negotiation stage we will agree access for BA and POCL
Service Managers to the Pathway Service Management System. For example,
limited direct access to the PCRC incident database may be required so that
progress on specific calls may be determined. Where direct access to systems is
not possible, BA and POCL Service Managers will be able to contact Pathway’s
service administration team for the required information.
PERFORMANCE
HELP DESKS
The CMS help desk will provide 24 hours per day facilities to BA customers to
report lost and stolen cards.
All other calls will be resolved by the PCRC operator or routed to the
appropriate specialist help desk. The contracted hours of the PCRC and the
specialist help desks will reflect POCL’s (and its clients’) opening hours and any
additional requirements. Where necessary, a 24-hour facility will be provided.
The target for answering all calls will be 95% of calls answered within 3 rings
(10 seconds).
FAULT DIAGNOSIS AND RESOLUTION
All fault calls will be referred to the appropriate software, hardware or network
support service. The PCRC incident database will record all activities
undertaken to resolve a fault.
Faults will be assigned a priority that reflects the caller’s perceived impact and
urgency of the fault. They will be classified A, B or C as shown in Fig. 7.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 20 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.4.6.2.3
5.4.6.3
5.4.6.3.1
5.4.6.3.2
5.4.7
5.4.7.1
Priority : I Will be assigned in these circumstances :
A Caller’s business function has stopped or is in danger of stopping
B Caller’s business function is significantly impaired
Cc Caller’s business function is only slightly impaired
Fig, 7 - Help Desk Call Priority Classifications
Faults will be actioned as follows :
(a) Priority A faults : These will receive the immediate and urgent attention of
the Pathway Service Manager who will assign one of his staff to own the
problem until it is resolved. The target resolution time for hardware and
network faults will be within 4 hours of logging the call and for software
faults within 24 hours of logging the call.
(b) Priority B faults : Hardware and network faults will be resolved within 4
hours and software faults will be resolved within 48 hours.
(c) Priority C faults : Hardware and network faults will be resolved within 48
hours and software faults within 7 days. Advice and guidance will usually
be given immediately.
CONSTRAINTS
In order that help desk target performance may be achieved, it is essential that
the help desk is not used as a substitute for effective management, training and
documentation within BA/POCL. Whilst the help desk is available for guidance
and advice, such calls should remain within acceptable levels, agreed between
Pathway and BA/POCL during the contract negotiation stage.
In order that faults may be resolved within the specified timescales, it is essential
that BA/POCL staff contact the help desk promptly, provide appropriate initial
information and make note of the allocated reference number. Should further
information be requested by the help desk, this must be provided within the
timescales agreed. During the period of fault diagnosis and resolution, a named
contact must be available for the help desk or their representatives to speak to
and, should a visit be required, access to the site must be made available.
CONTRACTING AUTHORITIES RESPONSIBILITIES
BA/POCL staff must ensure that access to post offices is allowed when required
for maintenance of the hardware, software and network components within
specified timescales.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 21 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.4.7.2
5.5
5.5.1
S511
5.5.1.2
5.5.1.3
5.5.1.4
BA/POCL staff must follow the agreed procedures in requesting help desk
facilities or other support services. Where it has been agreed that only certain
staff may access services (for example, request software changes), these
restrictions must be respected.
POTENTIAL DISASTER SCENARIOS
INTRODUCTION
This sub-section addresses several potential disaster scenarios relating to
Pathway’s operational services. It describes the actions that will be taken by
Pathway staff to manage serious problems from the moment they are recognised
to the point where normal service has been resumed.
Pathway will treat these situations with the highest priority.
In every case involving temporary or more persistent loss of service, the
Pathway Service Manager will appoint one of his staff as Problem Manager to
take personal responsibility and ownership of the problem. He will
continuously monitor progress and liaise between the various subcontractors
and BA/POCL staff ensuring that at all times the proper agreed procedures are
being followed. After each incident, a formal review process will pinpoint the
root cause of the failure and recommend action to prevent it from happening
again.
The diagram in Fig. 8 identifies seven points at which serious problems could
manifest themselves.
x1
‘ 4
I
CMS Systems PMS Systems
Fig. 8 - Seven Potential Disaster Points
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 22 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.5.2
5.5.2.1
5.5.2.11
5.5.2.1,2
5.5.2.1.3
S.5.2.1.4
5.5.2.2
5.5.2.2.1
5.5,2.2.2
COUNTER SYSTEM FAILURE (1. & X2)
Statistically, with more than 40,000 counter positions in operation, this is the
most likely area to experience potential problems. Pathway’s service
architecture does provide, however, maximum resilience to the failure of any
system component at the counter.
MULTI-COUNTER POST OFFICE
Consider point X1 in Fig. 8. There is a fault with the system at one of the
counter positions but the other counter positions are still operating normally.
The Riposte software automatically replicates its transaction and stock data to
all other counter positions in that post office. So, if another counter position is
available, the counter clerk would simply move to that position and carry on
working. Data is only replicated when a transaction is completed. This means
that if the counter clerk was half way through a transaction he would have to
begin that transaction again from the beginning.
If no other counter position was available then the customer would have to join
the queue and begin the transaction again.
When the fault has been repaired, the system will automatically recover itself
and bring its transaction and stock data up-to-date with all of the other counter
positions in the post office.
SINGLE-COUNTER POST OFFICE
In this case (X2 in Fig. 8), the post office must revert to fall-back procedures
until the system has been repaired and recovered. The underlying support
Service Providers are committed to specific call-to-fix times, limiting the period
of fall-back to four hours.
Fall-back procedures will be formally agreed and documented with BA/POCL
and all staff trained in their use. During this time the post office must be able to
conduct its normal business and continue to pay benefits, Pathway has
considered two procedures for dealing with temporary failure of the counter
system to enable benefit payments to continue to be made :
(a) Telephone contact is made with the PMS help desk which will provide an
authorisation code and the value to pay. The help desk will record the
payment on PMS enabling a formal audit of these transactions.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 23 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5S - STEADY STATE SERVICES
5.5.2.2.3
5.5.3
5.5.3.1
5.5.3.2
5.5.3.3
5.5.3.4
5.5.4
5.5.4.1
5.5.4.2
(b) In the most severe case, where the failure persists for a longer period or
where the volume of claims cannot be managed sensibly through telephone
authorisation then the PMS help desk will arrange for the secure printing
and delivery of the post office’s extract from the Payable Payments Report.
This will then be used as the basis for local payment authorisation within
the affected post office.
In both (a) and (b), paper receipts will be issued to customers and a copy
retained by the post office for the purpose of manually updating the system
when the fault is fixed and the system has automatically recovered its data from
TMS.
TMS SYSTEM FAILURE (X3)
TMS is run on multiple servers geographically dispersed across multiple sites.
Its architecture provides for the automatic back-up of data between servers on
different sites. Payment and counter transaction data for each post office is
therefore maintained and available from several servers.
In the event of its default server (X3 in Fig. 8) being unavailable, the counter
system will be connected automatically to an alternative server. This will
happen without the knowledge or intervention of the post office staff.
When the TMS fault is repaired the server will automatically recover itself and
normal connection will be restored to its nominated post offices,
Pathway’s design ensures that TMS failures will not be detected by any
BA/POCL user. Its performance and availability is constantly monitored by a
network management system and failures are automatically notified to the help
desk.
BPS SYSTEM FAILURE (X4 & X5)
Both the CMS (X4 in Fig. 8) and the PMS (XS in Fig. 8) systems platforms are
fault-tolerant multi-processor machines geographically split across two sites with
each site having the processing capacity to handle all of the workload normally
shared between them.
If one of the sites experiences a major disaster (for example a serious fire
disables the site for an extended period), the other site’s processor can carry on
with no perceived deterioration in service to BA/POCL.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 24 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION S - STEADY STATE SERVICES
5.5.5
5.5.5.1
5.5.5.1.
5.5.5.1.2
5.5.5.1.3
5.5.5.2
5.5.5.2.1
5.5.5.2.2
5.6
5.6.1
5.6.1.1
5.6.1.2
NETWORK FAILURE (X6 & X7)
COUNTER INTERFACE IS ISOLATED FROM TMS
In the event of a catastrophic failure within the network linking the counter
interface to TMS during working hours (X6 in Fig. 8), the ability to make
benefit payments will continue unimpaired using the local payment
authorisation files. These files contain payment data for 48 hours of advanced
processing.
Foreign payments and emergency payments at the affected post office will
require manual authorisation of the payment value but the system will continue
to support the recording of encashments and receipting. The authorisation to
pay in these cases may be obtained over the telephone from the PMS help desk
which will check the system to ensure that no foreign payments have already
been made thus preventing payment from being made at other post offices.
When the network connection is restored, the counter interface will
automatically bring TMS up-to-date with its transactions.
BPS IS ISOLATED FROM TMS
A failure in the network linking BPS to TMS (X7 in Fig. 8) will have the most
severe impact if it occurs during the distribution of payment authorisations from
PMS.
In this case, because CAPS sends due payment data 48 hours in advance, there
will be a 36 to 48 hour window before further payment data can be input.
During this period the network would be repaired and it will be necessary for
BA staff wishing to issue changes to the status of a particular payment (such as a
stop notice) to do it by telephone or other means to the nominated post offices
until the network has been recovered.
CONTRACT MANAGEMENT SERVICE
INTRODUCTION AND OVERALL APPROACH
The Contract Management Service will be developed as the pilot phase
progresses and processes and procedural documentation are reviewed and
accepted. Pathway and BA/POCL will agree the scope of the service prior to the
commencement of the procurement. The full contract management service will
be brought into operation following roll-out of the first post office.
BA/POCL will see an efficient and well-managed end-to-end service. Pathway
confirms that it will provide a single point of contact for all contractual matters.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 25 of 54
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.6.2.1
5.6.2.2
5.6.2.2.1
5.6.2.2.2
5.6.2.3
5.6.2.4
5.6.2.5
SCOPE OF THE CONTRACT MANAGEMENT FUNCTION
Pathway proposes that the scope of the contract management function be as
described below :
MONITORING SERVICE PERFORMANCE STATISTICS
Operational procedures will be developed detailing the activities to be
undertaken for each service. Service levels will be agreed for each service
providing response times and quality performance. Pathway will monitor
performance against Service Level Agreements and provide the necessary
information to allow problems to be reviewed continuously between BA/POCL
service managers and Pathway service managers.
CONTRACT AUTHORITY /SERVICE CONTRACTOR REVIEWS
Regular formal monthly executive meetings will be held between Pathway and
BA/POCL senior representatives. These meetings will provide a forum to
discuss service levels and customer satisfaction and will allow the opportunity to
discuss and resolve any issues.
Issues requiring a formal change agreement will be discussed and referred to the
Change Control Board described in Section 5.6.2.4.
ESCALATION PROCEDURES
Issues that are unresolved at the executive meetings must be referred to the
Managing Director of Pathway and if necessary to the Board and to equivalent
representatives of BA/POCL.
CONTRACT CHANGE MANAGEMENT
Contract amendments will be referred to the Change Control Board which
comprises members of the BA/POCL and Pathway Boards of Directors.
Changes will be agreed after careful assessment of their impact on costs, service
levels and operational processes. Agreement must be obtained from both parties
before any amendment is made. Requests to change the contract must be made
in writing and the other parties must respond in writing within one month.
Formal contract variations will be drafted and signed by all relevant parties prior
to the change being implemented.
SERVICE CHANGE MANAGEMENT
Changes to the service will be made by changing the relevant operational
procedures. In order to make such changes Pathway or BA/POCL will advise
the other at least one month prior to implementation. If the amendment
materially affects the operation of the contract, it may be requested that the
contract be changed.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 26 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.6.2.6
5.6.2.7
5.6.2.8
5.6.2.9
5.6.2.9.1
5.6.2.9.2
5.6.2.9.3
CHARGES AUTHORISATION
Pathway will undertake to provide BA/POCL with details of charges which as
far as possible reflect their organisation and meet their information needs.
These could be by client and by product, or any other format agreed during the
contract negotiation stage. Charges will reflect the serviceability and value of
the system and will be fully auditable.
AUDIT CONTROL AND ACCESS
Audit trails will exist for any action that generates access to the system, changes
to the system, or movements of data. On a daily basis the balancing will ensure
data integrity and processing accountability for all clients and products.
Pathway systems and procedures will be audited internally on a regular basis and
whenever significant changes are made. Independent audits will take place on at
least an annual basis and Pathway will co-operate at all times with suitable
organisations representing BA/POCL (for example, The National Audit Office).
SECURITY
Pathway is fully aware of the need for security in the BA/POCL system.
Pathway has developed its own security policy (documented in Annex 5) which
is derived from the best demonstrated practices of its shareholders and tailored
to meet the requirements of the BA/POCL systems and any threats to which
these systems are subjected. We have also developed information security
practices and standards which will be applied to all of the IT solutions we
propose.
QUALITY MANAGEMENT
Pathway’s Quality Policy, is described in Annex 2. It is based on the proven
foundations of the Strategic Quality Model developed by the European
Foundation for Quality Management and used extensively by other service
industries. The policy and its implementation are the responsibility of the
Director, Quality and Risk Management. All Directors are accountable for
implementation and management within their own areas of responsibility.
The philosophy of Pathway involves a quality and continuous improvement
culture. All staff will be trained in all aspects of quality and responsibility
devolved to the full level of their capabilities.
It is Pathway’s intention to gain ISO9001 accreditation. To this end, all
processes and procedures will be defined and relevant documentation provided
within the quality management system.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 27 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.6.2.9.4
5.6.2.10
5.6.2.10.1
5.6.2.10.2
5.6.2.10.3
This approach to quality management has been implemented successfully across
ICL and in particular on major large development contracts such as Camelot (see
Annex 6.4). Girobank was the first financial institution in the UK to receive
1S09001 for operational services.
SERVICE CODE OF PRACTICE
Pathway confirms that it will develop a range of procedures and practices which
define in detail the day-to-day service, the operational and management
interfaces and the relationships between BA/POCL and the Service Provider.
This set of procedures will be referred to as ‘The Service Code of Practice’ and
will be modelled on the code of practice issued by the Computing Services
Association. It is planned that this set of procedures will consist of the
following documentation :
Operational Procedures Manual
Pathway’s Operational Procedures Manual will confirm to BA/POCL that
Pathway’s quality business is carried out in a professional manner in an
environment that has an organisational structure where responsibilities,
procedures and processes are identified, documented and implemented
effectively. This will also include arrangements to ensure the work of the
subcontractors is properly monitored and controlled.
The Code of Behaviour Standard
All Pathway employees will be required to adhere to Pathway’s policies to
ensure that they uphold the high standards demanded. Pathway will insist on
the highest standards in terms of appearance, courtesy and politeness when
dealing with BA/POCL staff and customers. Pathway will place the utmost
importance on ensuring that employee checks are thorough and reliable.
Information gained during the course of business is deemed confidential and
will not be used for personal gain or any purpose other than for which it was
originally intended.
The Customer Charter
Customer charters will be developed for those services provided directly to
customers in line with the existing charters produced by BA/POCL. They will
provide all customers with a service that meets their expectations and needs.
For example, services provided to BA customers will be targeted to ensure
transactions are completed quickly at the post office counter and the right
person is paid the right amount in the right place at the right time, achieving
total satisfaction, first time, on time and every time.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 28 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STA’
5.6.3
5.6.3.1
5.6.3.2
5.7
5.7.1
5.7.1.1
5.7.1.2
5.7.1.3
5.7.1.4
A VIEW FROM THE USER’S PERSPECTIVE
BA/POCL will review system performance based upon the extensive MIS and
reporting available and all aspects of performance will then be the subject of
regular dialogue between BA/POCL and Pathway.
Changes to the contract will be approved by the Change Control Board and
approaches to the subcontractors will be handled directly by Pathway resulting
in the provision of a well-structured end-to-end service.
CONTRACT TRANSFER SERVICE
It is recognised that, towards the end of the initial contract term, the contracted
service is likely to be re-opened to competitive tender and that Pathway may not
be successful in securing a renewal of contract or that the renewal may be only
partial. This section considers the implications of contract transfer and proposes
how Pathway would support it.
OVERVIEW
One of the challenges associated with a close partnership approach is the
achievement of a clean and orderly separation. Pre-requisites are careful
planning and professionalism. Pathway will commit itself before the initial
contract to supporting downstream contract transfer to another Service
Provider. Pathway commits that it will act in a professional manner and
continue to give the highest priority to the maintenance and performance of its
services during the transfer period. To the extent that the performance of the
new Service Provider becomes an additional dependency outside its control,
Pathway cannot guarantee success.
Contract transfer will require a transition period and additional services to
ensure a seamless transfer to the in-coming Service Provider. Careful attention
will have to be paid to service boundaries, the allocation of responsibilities and
resource matching,
We envisage that at the appropriate time a package of services will be agreed
between BA/POCL, Pathway and the new Service Provider which defines clearly
each of these elements. Such a package would include an extension of steady
state services for an agreed period. The combination forms a ‘Service Transfer
Contract’, and will be a tri-partite agreement.
We expect to enter into a contractual framework with BA/POCL ahead of the
initial contract to set out the operational and commercial ground rules for what
will happen at the end of the contract. A range of scenarios and how each
would work will be covered.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 29 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.7.1.5
5.7.1.6
5.7.2
5.7.2.1
5.7.2.2
5.7.2.2.1
$5.7,.2.2.2
3.7.2.2.3
Pathway proposes to adopt the Computing Services Association Facilities
Management Code of Practice. This will be our guide to the conduct of the
transfer. Through ICL CFM, Pathway has the experience of such transfers at
contract end all of which have been successfully conducted. There are many
examples, including Berkshire District Council, London Borough of Greenwich
and Mersey Regional Health Authority.
The remainder of this section provides a preliminary operational perspective on
how transfer would be approached and anticipates the range of requirements.
Section 8 considers the commercial implications.
PARAMETERS FOR CONTRACT TRANSFER
There are a number of operational parameters to be considered :
¢ Service imperatives and constraints
© The degree of service contract transfer
* The degree of difference in technical design, old to new
« Human resource matching from Pathway to the new Service Provider
¢ Effecting financial resource transfer
* Managing responsibility and risk transfer
SERVICE IMPERATIVES AND CONSTRAINTS
The overriding imperative must be to achieve transfer without any disruption to
services. BA/POCL must know before they let the initial contract that they will
be able to transfer it at the end of the term without unduly risking service levels.
The approach set out below should provide some initial re-assurance (to be
developed further in discussion during the demonstration phase) that we have
considered the matter carefully and have the capability to meet the imperative.
The requirement to effect transfer within reasonable timescales is also accepted.
We would expect BA/POCL to have two primary concerns :
© The ability of the new Service Provider to effect a smooth transfer
* Assurance that it will do so when the time comes
Demonstrating ability is addressed below. Sustaining a service to the required
service standards over a protracted period when management and staff will be
aware that the contract has been lost, is likely to be difficult for the Service
Provider. It is therefore in his interests to effect a rapid transfer.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 30 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.7.2.3
5.7.2.3.1
5.7.2.3.2
5.7.2.3.3
5.7.2.4
5.7.2.4.1
5.7.2.4.2
THE DEGREE OF SERVICE CONTRACT TRANSFER
The degree of service contract transfer is bounded by :
¢ Total loss or transfer, assuming that the initial contract was for the entire
service
* Loss or transfer of just one component
The characteristics are different in each case. If the entire service contract is to
be transferred, the principal considerations relate to the orderly transfer of
services from one infrastructure to another. If only one component of the
service is be transferred, the task will be to replace one component with another
at a well-defined boundary whilst maintaining all other aspects of the service.
Variations include transferring the whole to more than one new Service Provider
and transferring more than one part to one or more new Service Providers.
Lack of process or technical compatibility would add complexity and risk to
service transfer. A generic transfer approach is proposed to ensure that such
issues are qualified early on and properly taken into account in the Service
Transfer Contract. This approach would :
¢ Define the process map from Pathway to the new services
* Define the logical design of the new end-to-end service
* Specify and agree the API of the service boundaries
* Specify and agree the transfer of data to the new service
¢ Trial the new service or components in parallel or integrated with the existing
services as part of a pilot activity
* Specify a substitution plan for service components or for total service cut-
over
THE DEGREE OF DIFFERENCE BETWEEN DESIGNS
Pathway’s approach will facilitate transition. However, standards move on and
there is no guarantee that compatibility will be assured in eight years’ time. In
part, standards compatibility will depend on the architecture that the new
Service Provider has chosen. Pathway will ensure that when a significant change
to standards is considered during the life of the initial contract, such changes
will only be made after full discussion with BA/POCL. Close association with
Microsoft will ensure the maximum possible future-proofing from the outset.
Depending on the design, logical service boundaries may also differ. For
example, there are boundary differences between a centralised PAS service and a
decentralised payment authorisation service controlled by a central payment
management (PMS) function. A centralised PAS system could be matched to a
decentralised system but is unlikely to deliver value for money.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 31 of 54
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.7.2.5
5.7.2.5.1
5.7.2.5.2
5.7.2.5.3
5.7.2.5.4
5.7.2.5.5
5.7.2.6
5.7.2.6.1
5.7.2.6.2
HUMAN RESOURCE MATCHING
Matching human and service resources of Pathway to the new Service Provider
will be an important consideration from several standpoints :
* Capability
* Individual motivation
¢ Aggregate cost
* Subcontract assignment
There are two approaches to contract transfer :
* Transfer of people and subcontracts
¢ Phased replacement of one service by another
Different degrees of resource transfer will be appropriate depending on the
compatibility of the technical approach, and physical location considerations.
Contract transfer is likely to result in the use of different subcontractors. It will
reduce transfer risk if key people are transferred or seconded beyond the
transition period. It makes good sense to consider the transfer of discrete
elements of service, such as help desks.
Both will depend in part on the preferences of the new Service Provider.
Pathway and its principal subcontractors are willing to consider such transfers or
secondments and can see benefit in doing so. It is assumed that transfers will be
under TUPE.
Once Pathway has agreed with BA/POCL the main clauses which support
contract transfer, Pathway will agree corresponding clauses with each of its
subcontractors.
EFFECTING FINANCIAL RESOURCE TRANSFER
The commercial and financial implications of contract transfer are considered in
Section 8. The principal components are expected to be physical assets and
software licences. In the event of loss of contract, it will be in Pathway’s interest
to transfer all the assets uniquely associated with the service to the new Service
Provider and we would wish to do so in a controlled manner as for a business
sale/acquisition. Software rights may, in many cases, be transferred but ‘shrink-
wrapped’ industry standard software is generally licensed to one user,
prohibiting its transfer.
It is less clear that the new Service Provider would wish to use existing software
or that he would be capable of doing so in practice. It is our assumption that
Pathway’s loss of the business would either be because of new software
becoming available during the initial contract period enabling a radically new
approach or because Pathway’s service has consistently failed to meet
BA/POCL’s requirements.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 32 of 54
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
5.7.2.7
5.7.2.7.1
5.7.2.7.2
I SRS.1
I SRS.2
MANAGING RESPONSIBILITY AND RISK TRANSFER
Managing responsibility and risk transfer will require careful co-ordination
between Pathway and the new Service Provider. During this period, BA/POCL
have two choices as to how to achieve transfer :
(a) Assign overall project management and end-to-end service responsibility to
the incoming Service Provider, with the outgoing Service Provider as
subcontractor
(b) Assume overall project management responsibility for the transition
themselves.
Pathway is prepared in principle to enter into a Service Transfer Contract on
either basis. Any framework agreed before the initial contract will have been
with Pathway. BA/POCL will therefore need to gain this agreement with the
incoming Service Provider or re-negotiate the contract with both.
SPECIFIC RESPONSES
This Sub-section presents Pathway’s responses to the specific requests for
information in Chapter 5.6.2 of the Statement of Service Requirements.
‘State any perceived dependencies between service levels that can be met by the
Service Provider and the service levels of interfacing computer services and
systems (e.g. CAPS).’
The data required by the POCL Strategic Infrastructure Service is self-contained
within Pathway’s systems and is therefore not dependent on external interfaces.
However, service levels for benefit payments may be adversely impacted if the
overnight batch data transfer from CAPS fails to complete on time. Similarly,
the total transaction time for British Gas Quantum payments may be extended
outside the control of Pathway due to British Gas’ system performance.
‘State the upgrade paths available for the proposed solution within the proposed
operating environment, clearly indicating the current (as at the time of the
response) maximum capacity for the service.’
Counter Interface
The proposed operating environment for the counter interface is Microsoft
Windows NT. Upgrade paths are limited by the hardware environment of the
PC (upgrade steps are described in SR5.3), rather than by any system limits
within the software. Windows NT release 3.5 supports memory sizes of up to 4
gigabytes, disk capacities of 2 bytes and symmetric multi-processors.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 33 of 54
OJEC Notice 94/S 165-58937/EN_ Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
As PCs within the counter interface operate independently within a replicated
community, additional PCs may be added within a post office as required.
Ultimately, constraints derive from the capacity of the ISDN communications
gateway, the local LAN and the capacity of the individual PCs themselves.
The answer to question SR4.6 provides more detail on the capacity of these
components. For the transaction profiles and volumes described in the SSR, the
most significant of these constraints on capacity is the ISDN communications
gateway, which supports transaction replication to a correspondence server at
approximately 30 transactions per second.
The design of the Benefit Payment Service minimises the requirement for ISDN
capacity by supporting local authorisation for the overwhelming majority of
payments. However, if required by the future growth of new business
applications, an additional ISDN line and communications gateway can be
configured, providing increased communications throughput and resilience.
Transaction Management Service
The proposed operating environment for TMS is Microsoft Windows NT.
Transaction replication and back-up is provided by the An Post/Escher Riposte
software. System limits for Windows NT are described above, although the
proposed design for TMS copes with scalability and upgrade paths by adding
additional servers as an alternative to increasing their individual capacity.
Pathway will configure the most cost-effective mix of servers to support the
capacity requirements as the service grows.
Initially it is proposed that Intel dual Pentium servers are deployed with
subsequent migration to symmetric P6 multi-processors. Based on the
transaction profiles and volumes described in the SSR, Pathway estimates that
the full network of 40,000 counters would require in the order of 24 to 32
Pentium servers, providing a capacity of typically 10 million transactions per
day. (See also the response to question SR4.6).
Payment Management Service
The proposed operating environment is Tandem Guardian D30. The maximum
capacity of a single footprint system is 1044 Gigabyte memory, 3060 terrabytes
disk storage and 4080 processors using the TorusNet bus extender. The design
of PMS enables upgrades to the service capacity to be made by extending the
batch processing window and/or providing additional batch processing streams,
according to operational needs. The maximum capacity of the system as initially
configured is planned at approximately 20 million transactions within a 12-hour
batch window.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 34 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 5 - STEADY STATE SERVICES
I SRS.3
On-line capacity for those aspects of PMS operating in real time can ultimately
be increased to the maximum supported by the hardware. The system as
currently designed can scale to support up to 6 million transactions per day,
although this would require an unrealistic rate of enquiries and payment stop
operations from BA offices.
Card Management Service
The proposed operating environment is Tandem Guardian D30. Pathway’s
design for CMS is based upon a mixture of batch and real time processing and
its capacity can be upgraded in the same way as for PMS. The capacity of the
service is planned to support up to approximately 100,000 records per day from
CAPS for new or amended cards, 20,000 card status change operations per day
and card status enquiries from BA offices (precise volumes will be determined in
discussion with BA/POCL).
‘State how upgrades will be undertaken, whether they can be undertaken in the
field and the steps in which the upgrade can be made.’
Counter Interface
Upgrades, where required, will fall into two categories :
* Installation of additional hardware or peripheral components or upgrading of
components within the existing PC will be undertaken in the field.
* Major upgrades, such as hard disk replacement, or complete PC replacement
will be undertaken in the field by unit swap-out, with return and recycling
where appropriate. These will require agreed arrangements for the
preservation of operational data and its transfer to the new unit, plus secure
removal of any existing operational data on the replaced unit.
The precise upgrade steps available will depend upon the final agreed set of
counter equipment and options. As an indication the baseline counter
configuration would allow for upgrade steps as follows :
* Memory: 16Mb with increments of 4Mb, 16Mb or 32Mb
¢ Hard Disk : 270Mb or 540Mb (2nd disk) or 1Gb (disk replacement)
* Processor : Pentium overdrive socket
Software upgrades will be handled via centrally controlled software distribution
procedures (described within the response to question SR5.15).
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 35 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
Transaction Management Service
TMS servers can be upgraded in terms of memory, disk capacity and additional
processor units, all of which may be fitted in the field. As the capacity of TMS
requires to be upgraded, Pathway will adopt the most cost-effective approach in
terms of the combination of upgrading existing equipment, adding additional
correspondence servers or replacing Pentium-based servers with P6-based
machines. Depending upon the particular combination of equipment in use,
indicative upgrade steps are :
¢« Memory : 64Mb increments
* Disk : 1Gb increments or 5Gb with RAID subsystem
* Processor : 2-way Pentium to 4-way Pentium or to Pé (future)
Card Management Service and Payment Management Service
CMS and PMS have similar upgrade capabilities. Servers can be upgraded in
terms of memory, disk capacity and additional processor modules. If the
capacity of CMS or PMS requires to be increased, Pathway will determine the
most cost-effective approach in terms of the combination of enhancement of
existing systems, replacement by new systems or the provision of additional
parallel processing capability.
I SRS.4 ‘Describe the ongoing development programme to which the service proposed is
subject, and state how it will provide an appropriate basis for the addition of
new facilities and technologies.’
The proposed service has been designed to meet the specific needs of BA/POCL
as expressed in the SSR and as the basis for ongoing developments to support
future business and technology changes. Specific areas of opportunity are
presented in Section 8.3 covering :
* Mail and parcel business
¢ Banking and financial services
* Bill payments and financial in-payments
* Licence applications
We look forward to the opportunity to discuss the establishment of an ongoing
development programme to meet these and wider business requirements. The
service proposed offers an excellent framework for ongoing developments of
this type.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 36 of 54
OJEC Notice 94/S 165-S8937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
Or} a
SECTION 5 - STEADY STATE SERVICES
I SRS.S
Counter Interface
Pathway’s choice of counter infrastructure offers potential access to a number of
existing and emerging applications within the above areas which can be easily
incorporated into the set of proposed counter applications. The use of
Microsoft Windows NT at every counter position, coupled with Microsoft
Systems Management Server, provides a robust, secure and manageable platform
which is the mainstream industry direction for enterprise-wide networks in the
office, retail and financial services industries. The Riposte Desktop
environment, generic transaction approach and standard development tools such
as Visual Basic and Microsoft Test enable new applications to be added quickly.
Transaction Management Service
Pathway’s proposals for TMS and the use of generic software agents to interface
to existing or new client systems provide a fast and flexible way to incorporate
new client services. The use of ISDN with TMS provides a flexible framework
to support transaction handling in real time, trickle-feed mode or file transfer
mode and provides a cost-effective route for the introduction of services
requiring faster communications than traditional analogue access.
Benefit Payment Service
The design of the Benefit Payment Service allows flexibility in positioning
payment authorisation data and optimising the end-to-end service delivery. The
inclusion of smart card technology at the counter and the support for local
authorisation enables straightforward and cost-effective migration to smart cards
within the BPS. These can be used to improve personal authentication data and
could be used in conjunction with PMS to transfer value-based information to
the card to support mobility or the use of alternative payment points.
‘State the service levels that are proposed for the availability and reliability of
the service at post offices; transaction transfer to and from client systems; and
for interrogations from BA offices.’
Indicative figures are provided in the table below for the service levels Pathway
would expect to offer. Further discussion will be necessary about the detailed
criteria used to define and measure service levels, including the assessed impact
of partial loss of service. Pathway proposes that a minimum and maximum level
of performance be established for each major category to facilitate measurement
and charging (See also the response to question SRS.8).
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 37 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION §$ - STEADY STATE SERVICES
Service Measure: Expected performance level :
Counter system 99.85 to 99.9 % of all counter positions in service
availability and reliability
>99,.9 % of all post offices in service
> 30000 hours mean time between loss of service
at a counter position
Transaction transfer >99.9% of scheduled daily client deliveries met,
between POCL systems excluding failures within client systems or their
and POCL client systems I communication interface
Availability for BA > 99.9% for BA working hours
interrogations
The reliability of individual components of the counter interface are given
below:
Fujitsu/ICL PC Model e440/66:
System Board 100,000 hrs
PowerSupply 100,000 hrs
HDD 540Mb 300,000 hrs
Floppy Disk 30,000 hrs
ICL Keyboard 300,000 hrs
ErgoPRO 14” colour monitor 14C 40,000 hrs
ICL 9” counter monitor C90C 30,000 hrs
ARL DOCUmatic 7000 motorized reader:
OCR, MSR, MICR, Bar Code wand 15,000 hrs (nominal)
Printers:
Fujitsu DL3700 dot matrix (back office) 8,000 hrs (25% duty cycle)
Ithaca SOPLUS counter printer 25,000 hrs
Service level agreements for batch file transfer will be agreed with POCL clients
at the contract negotiation stage.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 38 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
I SRS.6
‘State the service levels that are proposed for transaction response times and
demonstrate that these will not adversely impact on current levels of service or
business for POCL clients.’
Indicative figures are provided in the table below for the service levels Pathway
would expect to offer in terms of service response times for particular types of
counter transaction. Further discussion will be necessary over the detailed
criteria used to define and measure performance, including the constituent
components of the total counter transaction response time. Pathway proposes
that a minimum and maximum level of performance should be established to
facilitate measurement and charging (See also the response to question SRS.8).
Transaction Type : Expected performance level
Payment authorisation at nominated post office I 1 second average
95% within 2 seconds
Payment authorisation at foreign post office 3-5 seconds average
95% within 8 seconds
Bill payment transaction capture of details 1 second average
95% within 2 seconds
EPOS transaction capture of details 1 second average
95% within 2 seconds
The overall counter time for a particular transaction is dependent upon a
number of factors. For the Benefit Payment Service this includes the printing of
the receipt with statutory declaration and obtaining the customer signature.
Pathway has analysed opportunities for reducing counter transaction times,
particularly drawing upon the counter automation experience of An Post.
We note from the SSR that the current counter transaction time for benefit
payments is 22 to 32 seconds. Measurements taken by An Post in Ireland using
the proposed counter interface system indicate a typical counter transaction time
for card-based payment in the range of 15 to 25 seconds. The use of local
payment authorisation files is of major benefit in reducing counter transaction
times, eliminating communications delays for more than 90% of benefit
payments.
Improvements in service to other clients are also enabled by the speed of
counter operations and by the elimination of overnight polling to capture data
centrally, The transaction replication within TMS continuously drip-feeds the
central processing systems enabling potential improvements in delivering
information to client deadlines.
We confirm our willingness to work with POCL to facilitate improvements in
counter transaction times and to agree detailed performance criteria and
measurement methods. One of the Pathway proposals is to establish a model
automated post office, which can be used to investigate and analyse
opportunities for such performance improvements.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 39 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
I SRS.7
I SRS.8
‘State the service levels that could be attained concerning the following :
(a) call to fix time for equipment failure;
(b) helpline queue times;
(c) any other service.’
Indicative figures are provided in the table below for the service levels Pathway
would expect to offer. Pathway proposes that a minimum and maximum level
of performance be established to facilitate measurement and charging (See also
the response to question SRS.8).
Service Measure : Expected performance level
Call to fix time for equipment failure 2 to 4 hours
Helpline queue times 3 rings (10 seconds)
Help desk first time fix rate 85 to 95% of enquiries resolved
within 10 minutes
Availability of reports Immediate to 72 hours,
depending upon nature of report
‘State how the service supplied can best be measured to facilitate payment.’
Pathway proposes that the service should be measured against agreed minimum
and maximum acceptable performance bands in a number of categories, such as
* Transaction throughput
* Card volumes issued and under management
* System response time
* System availability
* Service response time for call to fix
Payment will be based upon agreed weightings of these performance bands, with
financial incentives or penalties awarded for performance outside these bands.
For example : Call to fix time for equipment failure
Measures Minimum I Maximum I Incentives Penalties
age first min% max% £bonus for each I £penalty for each
time fix rate I within within %age point %age point
x hours x hours above the below the
maximum minimum
Capped at x%
Service measurement criteria will be agreed at the contract negotiation stage
together with the format and frequency of generation of reports describing the
Pathway service performance.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 40 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5S - STEADY STATE SERVICES
I SRS.9
Pathway will provide facilities to extract appropriate charges information from
volumetric analysis of the transaction data passing through TMS, across the
interfaces between CAPS and CMS/PMS and between BA offices and CMS.
Access to information and audit trails will be made available in response to
specific enquiries.
‘State how the service will enable the post office clerk accurately to pay valid
payments even if technical equipment is not working, and to make payments in
case of industrial action affecting the Service Provider or its subcontractors.’
All faults and problems affecting the system should be reported to the help desk
immediately and the best course of action agreed.
Counter interface failure
In multi-counter post offices, payments will continue using a reduced number of
positions as all counter PCs have a local version of all payment authorisation
files. When the failed PC is restored, it automatically recovers details of all
payments made at other counter positions during the period of its failure. If the
number of counter positions available does not cater for the level of customer
traffic, manual payments may also be made, using the procedures detailed
below. Single-counter post offices will normally use manual payment
procedures under these conditions, although customers may also be redirected
to alternative local post offices, if appropriate.
Communications network or TMS failure
In the event of a catastrophic failure within the network (or within the PC
containing the ISDN card) during post office working hours, the ability to make
benefit payments will continue unimpaired using the local authorisation files.
Foreign payments or emergency payments at the affected post office will require
manual authorisation of the value to pay, but the system will continue to
support the recording of encashments and receipting.
In the event of a network failure during the distribution of payment
authorisations, there is a window of between 36 and 48 hours before further
due payments data is required at the counter interface. During this time, the
network may be repaired. In the event of a persistent network fault, provision
will be made for the distribution of payment files by diskette to the affected post
office.
While the network is unavailable, any changes that BA wish to make to the
payment status of a particular payment, (for example, a stop notice), must be
telephoned or sent by other means to the nominated post office.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 41 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
PMS or CMS failure
A failure of the PMS batch processing functions may be recovered within the 36
to 48 hour time window prior to distribution of payment authorisation files.
Manual authorisation procedures
It is proposed that manual authorisation be handled in two ways.
(a) Telephone contact with the PMS help desk will provide authorisation and
the value to pay under agreed operational procedures. This will be the
norm for most categories of failure and the help desk will be staffed
appropriately. If voice communication from the affected office is also
unavailable, contact with the help desk must be established by alternative
means and procedure (b) followed.
(b) In the most severe cases where the failure may persist and/or the volumes
cannot be managed through telephone authorisation, the help desk will
arrange for the printing and secure delivery of the appropriate extract from
the Payable Payments Report. This will then be used as the basis for local
payment authorisation within the affected post office.
Payments will be made manually in accordance with agreed operational
procedures, including adequate proof of identity. Manual receipts will be issued
to customers and, using these, the payments file will be updated when the
system has been restored.
(Note that the introduction of smart cards at a future date would enable a
number of simplifications to the above procedures, particularly those relating to
foreign payments and network failure conditions.)
Contingency procedures
Should technical equipment failure or industrial action result in more than 24
hours loss of service, contingency arrangements will be invoked. Such
arrangements will need to be agreed between Pathway and the Contracting
Authorities during the contract negotiation stage and may include rights, in
appropriate circumstances, to access information held on PMS, This would
allow the Contracting Authorities to produce Payable Payments Reports for
despatch to all post offices.
I SR5.10 ‘State how the CMS customer services will be provided and promoted.’
The CMS help desk will provide a 24-hour direct-line service for customers
reporting lost, stolen and damaged cards.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 42 of 54
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
I SRS.11
The CMS help desk telephone number, together with details of the services
offered to customers, will be advertised in correspondence enclosed with the
PUN. The telephone number and services will also be promoted in all major
telephone directories under a number of headings, as well as by a series of
poster campaigns in BA offices and post offices. Information will also be
printed on the reverse of the card to assist with the use of the card and the help
desk.
It is recognised that the help desk may be used by customers for other types of
enquiry. Where possible, the call receptionist will deal with the enquiry and, if
necessary, refer them to their nearest BA office.
‘State recommendations for the training services that should be available for
the steady state operation.’
Pathway will ensure that all relevant BA/POCL staff are fully trained in all
aspects of the system operation, including self-help processes for simple
problems.
Training services will be available from Pathway from commencement of roll-
out and will cover :
(a) Initial system training for newly automated post offices, including :
* Operation of the counter system
* Generation and interpretation of reports
* Production of the Cash Account
* Reconciliation
* Cash and stock management
* Local office routines
* Self-help techniques
(The provision of these services is described in the answer to question
SR7.3 as part of the roll-out proposals.)
(b) New product introduction, including :
¢ Incorporation of new procedures
* New applications
* New client interfaces
(These will be delivered by a combination of computer-based training,
workbooks and usage of the system in training mode.)
(c) Training of new post office staff in the working of the Pathway system will
be incorporated within the standard five-week POCL staff training course.
(d) Ongoing training, via the help desk, to assist with routine problems and
questions.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 43 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
I SRS.12
The proposed system management facilities include provision for remote help
sessions on the counter PCs, enabling central help desk staff to guide the user
through a difficult task or perform the task directly, as appropriate. This will
have particular value during early systems usage.
BA staff who will interact with the new service may also require some training
and further discussion with BA is proposed to ascertain the precise requirements
and most appropriate approach. This will cover the use of the CMS system by
BA staff for card enquiries, monitoring and control operations and any
information necessary to support the indirect use of PMS via the CAPS service
interface.
‘State recommendations for customer education and marketing.’
Customer education
Successful implementation of the new services will depend on the reliability and
excellence of the technology being deployed, as well as its acceptance by
BA/POCL staff, clients and customers. The need for understanding and
awareness is vital, and Pathway’s ability to plan, implement, and support a
comprehensive and professional staff training and customer education campaign
will be key to success.
Pathway will commission comprehensive market research to ensure that we
know which services customers are looking for, and how they will react when
we introduce new services. Pathway proposes to use appropriate forms of
advertising to communicate relevant messages which provide clear information
about the services to all user groups. There are four key communications
objectives :
* To educate customers about the changeover to new services and manage their
expectations
* To inform customers when their service will be affected
* To ease customers’ anxiety
* To educate and inform the general public about the benefits of the new
service to avoid potential opposition
Advertising media will be selected from television, radio, bill-boards, posters,
direct mail, point of sale, direct response TV and others. To monitor the
success of the customer education campaign, and develop improved
communications, Pathway will commission customer surveys in each region
where new services will be introduced. In this way, we will address the people
aspects of the new services and ensure that automation is perceived to be a
success.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 44 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
I SRS.13
Marketing partnership
Pathway’s marketing approach is summarised as follows :
* To build on POCL’s current position through a partnership that combines the
strengths of POCL with those of Pathway and uses automation as a catalyst
for growth
* To assist POCL in improving the value for money offered to existing clients
« To encourage the use of tried and tested business development processes to
grow existing and new business
* To assist POCL in becoming the natural first choice for all existing and
proposed services
Pathway appreciates the major business opportunity presented by POCL as a
primary outlet for existing and new clients’ services. Pathway will work with
POCL to create an integrated process that unlocks this growth potential. We
will base this process on the one established by POCL and Girobank for
financial in-payments, which has resulted in unprecedented growth in this area.
Pathway will work in partnership with POCL to establish quantified business
development objectives based on combined strengths and a shared vision. The
key objectives will be :
* To optimise POCL volumes
* To maximise POCL income
* To identify and implement innovative services for new and existing clients
* To develop and implement commercial plans with principal clients
Further details of Pathway’s approach to marketing and business development
support is provided in Section 8.3.3.
‘State recommendations for the documentation that should be available for the
steady state operation.’
Pathway will develop a service operations manual and user guide for each of its
services. These will cover all aspects of access to, and the operation of, the
services by BA/POCL staff. A training guide and computer-based training for
the counter interface will be developed to support new staff.
Pathway will develop a support service guide for BA/POCL staff. This will
provide details of each of the support services available from Pathway and how
they may be accessed, including instructions on how to log calls and obtain
support from Pathway’s help desk services.
Fall-back and emergency operations procedures will be formally agreed and
documented and available to every BA/POCL user.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 45 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
Interface specifications between Pathway service systems and external systems
will be available.
A number of documents developed to support the roll-out, such as planning and
site preparation guides, are detailed in the response to question SR7.4. These
will continue to be maintained as reference documents during the steady state
service. All documentation will be developed to ISO9001 standard.
I SR5.14 ‘State the level of project support that will be provided to support the steady
state operations of the service, in terms of the number and qualifications of
people assigned to the project, the proportion of their time which will be
devoted to the project, and where they will be located.’
The level of project support to be provided to support the steady operations of
the service is indicated in the following table, together with an indication of
qualifications, proportion of time to be devoted to the project and intended
location : (This table excludes direct operations staff.)
Role Qualifications Minimum I Minimum I Location
Numbers I Time
Allocation
Pathway Senior executives from 7 100% Feltham
Directors shareholder companies
Commercial I Commercial and financial I 3 100% Feltham
& Finance consultants with 5 to 10
years experience
Quality & Quality and risk 3 100% Feltham
Risk management consultants
Management I with 5 to 10 years
experience in the
IT/Financial Services
industry
Business Business consultants with I 5 100% Feltham
Development I 5 to 10 years experience in
the Financial Services/
Retail industry
Technical Professional systems 5 100% Feltham/
integration I Terminal I
specialists/TickIT with House
3 to 10 years experience in
the IT industry
Programmes I Project managers with 5 100% Feltham
5 to 10 years experience
Operations Process managers with 2 to I 9 100% Bootle
5 years experience in the
Financial Services industry
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 46 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 5 - STEADY STATE SERVICES
I SRS.15
The above table refers to steady state operations following full roll-out.
However during the roll-out period which commences following automation of
the first post office, it is expected that additional resources will be required to
manage this transitionary period. ( See also the response to question SR7.5).
“Describe the logistics for introducing new, or new versions of, software
(including third party products) and in particular state how the following
functions would be carried out :
(a) _ initiating and logistics planning of version change;
(b) testing;
(c) code control;
(d) implementation planning;
(e) authorisation to implement;
(f) implementation;
(g) regression in the event of problems;
(h) training and document revision;
(i) configuration management update.’
Pathway will operate to clearly defined procedures for software version control,
agreed with BA/POCL, to ensure that the logistics for introducing new versions
of software are fully understood by all parties and embody appropriate control
mechanisms.
Pathway will incorporate a validation and integration centre (VIC). The VIC
will have the responsibility for all procedures relating to the validation,
integration and implementation planning of new software versions and related
documentation.
(a) Initiating and logistics planning of version change
The VIC will identify the scope and implications of any new software
version, in particular identifying compatibility issues, changes to operational
procedures and end user implications, such as training and documentation
requirements.
Where several software components require co-ordinated changes the VIC
will have responsibility for identifying and testing valid combinations to
ensure the logistics of the combined changes are understood, and defining
practical implementation and regression paths.
Any implications on BA/POCL, their client systems, operational procedures
or user interface will be identified and discussed. Software version changes
will be categorised according to their scope and system implications, with
standard procedures and authority levels set for each category of change.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 47 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
(b) Testing
Testing will be undertaken within the VIC, with particular emphasis on
compatibility and logistics issues. The VIC will identify any parallel running
and pilot activities required to establish confidence in the new software
before roll-out. Quality targets will be defined for the number of software
errors (categorised into critical, major and minor) which are acceptable at
each stage of the testing and implementation procedure.
(c) Code control
Control of code will be maintained centrally, using system management
tools to define and manage version control information. A formal issue
procedure will be used to transfer code versions from testing to
implementation stages.
(d)
Implementation planning
The VIC will identify all necessary implementation steps for each category
of version change, reflecting its scale and scope. These will include
activities required within Pathway, plus any activities to be planned in
conjunction with BA/POCL or any POCL clients. Dependencies will be
identified and managed where applicable.
For all significant software implementations, Pathway would wish to follow
a suitable project management methodology acceptable to all parties
involved. We have proposed the use of PRINCE in this role during the
demonstrator phase.
(e) Authorisation to implement
The standard procedures for each category of version change will identify
the authorising parties and level of authorisation required to move to
implementation. A formal sign-off mechanism will be established
incorporating assurances that :
¢ Software quality targets have been met
¢ Documentation and training, where required, is in place
¢ Any other necessary activities have been planned
¢ A regression route has been defined
Authorising parties will always include Pathway’s Technical Director and
Quality Director and their BA/POCL counterparts.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 48 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
iw
SECTION 5 - STEADY STATE SERVICES
(f) Implementation
The appropriate implementation approach will be followed according to the
category of software change. Software versions will be distributed and
installed across the network using Microsoft’s SMS software distribution
facilities. Implementation will be planned so as to minimise impact on
operational activities at post offices, typically occurring overnight.
(g) Regression in the event of problems
Implementation planning procedures will identify the necessary quality and
acceptance criteria for the new software version; in the event of these not
being met regression to the previous version will take place. This will also
be controlled centrally, using system management tools.
(hy
Training and document revision
The version change planning activities will identify any training and
documentation revisions associated with the software upgrades. Training
requirements will fall into the following categories :
* No user training necessary (software changes wholly transparent to the
user)
* — System broadcast facilities to inform staff of minor changes
* Computer-based training provided and distributed prior to software
implementation
* System training mode provided as part of the new software
* Familiarisation training required, on- or off-site, prior to the new
software version
Documentation requirements may involve :
* Revisions to existing material
* New documentation to be issued
(i) Configuration management update
The system management facilities will capture and maintain information
relating to all configuration data within the counter interface and TMS. The
proposed system management facilities support filtering of configuration
management data by means of combinatorial operations on property values
(for example, display details of all PCs with version X of software module
Y, and peripheral of type Z). Filtering can also be used to control selective
software distribution and installation.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 49 of 54
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
SECTION 5 - STEADY STATE SERVICES
I SR5.16 ‘Describe the field engineering operation and in particular state :
(a)
(b)
(c)
(d)
(e)
p
(g)
The
suggested call to fix times including any geographical differences;
escalation levels and procedures;
policies on ‘swap out’ versus ‘on-site repair’ of faulty equipment;
involvement, if any, with the recovery of any locally held software or data;
arrangements for ensuring availability and confidentiality of any locally
held data on equipment removed from post offices;
involvement, if any, with the introduction of new, or new versions of,
applications;
any routine preventive maintenance requirements.’
field engineering operation
This will be provided by Pathway through ICL Sorbus, the leading independent
multi-vendor service organisation in Europe. Within the UK it employs over
310
0 staff of which some 320 are field engineers dedicated to supporting PC
systems.
(a)
(b)
Call to fix times
ICL Sorbus provides a level of service specific to the needs of its customers
and their end users. In relation to the service required by individual post
offices we suggest that a 4-hour call to fix time would meet the requirement,
as was contracted for the POCL ALPS project. Pathway would be happy to
provide this level of service throughout the UK.
Geographical differences exist only where road transport communications
are very restricted, for example, in some of the more remote parts of
Scotland. However, the standard level of service cover can still be provided
but at additional cost. Pathway would be pleased to discuss specific service
levels for post offices in such areas during the negotiation stage.
Escalation levels and procedures
Through ICL Sorbus, Pathway will operate escalation procedures
conforming to IS09001 quality standards. This ensures that problems are
escalated to the appropriate authority and, if necessary, to ICL Director
level.
Pathway Response to
COMMERCIAL IN-CONFIDENCE Page: 50 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 5 - STEADY STATE SERVICES
Pathway’s proposed escalation times are described in the table below.
Time : Escalate to : Reason :
0 mins Pathway help desk All Calls
5 mins ICL Sorbus help desk All Calls
60 mins I ICL Sorbus help desk No estimated time of arrival
manager given
120 mins I ICL Sorbus support No estimated time of arrival
manager given
180 mins I Pathway service manager Calls that could exceed the
agreed service level
240 mins I Pathway Operations Call exceeds agreed service
Director level
‘c) ‘Swap out’ versus ‘on site repair’
ip
In order to minimise disruption to counter staff and customers, Pathway
proposes to operate a ‘swap out’ policy for all items of equipment rather
than causing disruption by repair on site. However, we would expect that
minor adjustments or maintenance would be attempted before units are
replaced.
Spares are managed to ensure that they are maintained to the latest
hardware modification (version) level. All whole unit spares and hard disks
will be loaded and configured with the appropriate system and application
software and checked for viruses.
(d) Involvement in software or data recovery
Field engineers will have no involvement in the recovery of locally held
software or data. Pathway’s design provides automatic recovery.
(e) Availability and confidentiality of data
Pathway, through ICL Sorbus, maintains equipment for a vast number of
top security customers, including the Ministry of Defence (MoD). As part
of the MoD CHOTS project, nearly 7,000 workstations over 12 locations
that are used by MoD corporate headquarters staff, involving secure access
and information, are maintained. (See Case Study 1 in Annex 6).
Pathway will treat all BA/POCL data as Company in Confidence. We will
not remove any information from site, in any format, unless requested to do
so to help diagnose a problem. If required, all copies of information made
to resolve a maintenance problem will be destroyed.
In order to protect POCL data security, if a disk is required to be replaced,
then the failed disk will be returned to a secure Pathway approved service
centre and destroyed.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 51 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
3 re
SECTION 5 - STEADY STATE SERVICES
(f) Introduction of new, or new versions, of applications
Field engineers will have no involvement in the introduction of new, or
new versions, of applications.
(g) Routine preventative maintenance
In 1991, ICL implemented the first phase of its preventative maintenance
strategy, called ‘PUMA’ (Prevent Unscheduled Maintenance Activity), which
is currently in place on all ICL’s major retail customer locations and some
200 mainframe customer sites.
Pathway will implement ‘PUMA’ to provide preventative maintenance
services. This will involve regular visits to clean delicate parts and replace
parts that are approaching the end of their life. In addition, electrical safety
tests will be carried out on all equipment to meet the 1989 Electricity at
Work Act. Site visits can be planned to avoid user and customer disruption
and minimise unplanned emergency maintenance visits.
I SRS5.17 ‘State what, if any, involvement from Contracting Authorities’ staff will be
required in the following processes :
(a) introduction of new, or new versions of, applications;
(b) routine back-up of any locally held software and/or data;
(c) hardware fault rectification;
(d) software fault rectification;
(e) communications fault rectification.’
(a) Introduction of new, or new versions of, applications
Contracting Authorities’ staff will receive training and documentation in
advance of any new, or new versions of, applications being introduced.
In cases where new applications interact across the service procurement
boundary with existing or new applications of the Contracting Authorities
or their clients, there will be a need to agree any required alterations to the
service interface and procedures for testing and implementation.
The response to question SR5.15 outlines Pathway's proposed procedures
for these purposes.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 52 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
us,
SECTION 5 - STEADY STATE SERVICES
(b) Routine back-up of any locally held software and/or data
No involvement of the Contracting Authorities’ staff is required for the
routine back-up of locally held software or data. The counter interface
system provides automatic back-up and recovery using local PCs and/or
TMS correspondence servers.
(c,d,e) Hardware, software and communications fault rectification
Contracting Authorities’ staff will be required to contact the help desk in the
first instance in the case of hardware, software and communications faults.
Where practical, they will be advised to undertake routine checks that may
restore the service. Faults that are not rectified in this way will be the
responsibility of Pathway.
Contracting Authorities’ staff will be expected to handle routine
replenishment of consumables, such as paper replacement, within the
counter interface service.
I SR5.18 ‘State details of the management information to be offered as part of the
service.’
Pathway will provide a comprehensive set of management information reports,
including :
* Daily cash analysis and post office balances
* Weekly Cash Account summaries
* Remuneration reports, as required
* Sales and contribution analysis
* Quality of service
Any other requirements, such as regular and ad hoc reports on BA payment
issues and encashments will be produced as agreed between Pathway and
BA/POCL. When further operational support services are introduced, Pathway
will provide management information reports for the following :
¢ Stock management
* Cash management
¢ Purchase order management
* Financial accounting, including General ledger, Fixed Asset register and
Purchase ledger
* Staffing statistics
* Administration support
Any new reports required will be subject to discussion and agreement between
Pathway and the Contracting Authorities.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 53 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 5 - STEADY STATE SERVICES
I SRS.19
‘Describe the reconciliation process for providing a complete, accurate,
automated daily reconciliation between the Service Provider's system and those
of the Contracting Authorities and propose methods to resolve discrepancies
that do not increase Contracting Authorities costs.’
All transactions will be input by the post office clerk at the counter interface
resulting in data capture of, at least, transaction type, volume and value. The
end-of-day procedure initiated by the Postmaster will produce a daily
reconciliation summary showing the value of transactions processed together
with cash and stock on hand. This information will be used by the Postmaster
to reconcile to the actual cash and stock in the post office.
POCL may wish to gather this information on a daily basis from all automated
post offices to give a national picture of daily transactions. This will be
necessary for full cash or stock management facilities.
Following full automation, POCL may wish to produce a daily Cash Account
reconciliation across all post offices. This will merely be an extension of the
daily reconciliation process completed by the Postmaster.
Any discrepancies between the Pathway’s and BA/POCL!’s figures will initially be
investigated by the Postmaster to ensure the calculations are correct. If
differences still exist after this, the Postmaster will be able to obtain a detailed
report showing the method of payment (cash, cheque, and so on) for each
transaction to enable resolution. This process is similar to current practice,
however, the provision of more comprehensive information will enable easier
resolution of differences and thereby reduce BA/POCL costs. The reconciliation
process is described in more detail in Annex 3.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 54 of 54
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION6 TABLE OF CONTENTS
6. PILOT PROGRAMME.
6.1 INTRODUCTION .......
6.2 PROVING APPROACH
6.2.1 BACKGROUND ..
6.2.2 PROVING PROCESS
6.2.3 PROVING MODEL .....
6.2.4 PROVING TECHNIQUES
6.2.5 BUSINESS PROCESS PROVING
6.2.6 SERVICE CHARACTERISTICS PROVING
6.2.7 TECHNICAL STRATEGY PROVING
6.2.8 WORKING RELATIONSHIPS .
6.2.9 RISK MANAGEMENT .
6.3. DEMONSTRATOR PHAS'!
6.3.1 INTRODUCTION .
6.3.2 DEMONSTRATIO! seeneeeeseneeees
6.3.3 DEMONSTRATOR PHASE CHECKPOINTS.
6.3.4 PROPOSAL BASELINE
6.3.5 AGREED BASELINE...
6.4, OPERATIONAL TRIAL PHASE
6.4.1 INTRODUCTION ........00+
6.4.2 OPERATIONAL TRIAL MODE!
6.4.3 OPERATIONAL TRIAL PHASE CHECKPOINTS .
6.4.4 CONTRACTUAL BASELINE ......sseeeeeeeeeereee
6.4.5 FINAL ACCEPTANCE........
6.5. PILOT PROGRAMME PROVING
6.5.1 INTRODUCTION ........c008
6.5.2 OVERALL PRIME CONTRACTOR CAPABILITY.
6.5.3 POCL PRIME NEEDS
6.5.4 BENEFIT AGENCY PR
6.5.5 CUSTOMER / CLERK NEEDS ......
6.5.6 TRAINING AND DOCUMENTATIO!
6.5.7 SERVICE DELIVERY........seceeeees
6.5.8 IT INFRASTRUCTURE
6.6. PILOT PROJECT PLANS
6.6.1 INTRODUCTION ....
6.6.2 MANAGEMENT STRUCTURE
6.6.3 DELIVERABLES
6.6.4 PILOT PROJECT
6.6.5 STAGE 1 BUSINESS PROCESS PROVING.
6.6.6 STAGE 2 SERVICE CHARACTERISTICS PROVING ..
6.6.7 STAGE 3 TECHNICAL ARCHITECTURE PROVING...
6.6.8 RESOURCING.....sseereseeeeee
6.6.9 RESOURCE DEPENDENCIES
6.6.10 COVERAGE MATRIX.
6.7 SUMMARY.....c10sseeee
6.8. SPECIFIC RESPONSES
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 6 - PILOT PROGRAMME
PILOT PROGRAMME
INTRODUCTION
This section describes Pathway’s approach to the pilot programme. Pathway
will use the pilot programme to prove to the BA and POCL its ability to provide
a viable roll-out solution. Our approach will deliver early benefits to BA/POCL
by building on existing systems. These include the POCL Electronic Stop
Notice System (ESNS), CounterAction that is in use by the Irish Post Office and
also applications that have been prototyped for the Singapore Post Office. All
these systems have been developed on a Microsoft and Riposte software
platform and are available to Pathway.
Proving that our solution meets the BA/POCL objectives is complex and
challenging. The way the process is managed is crucial to its success, Pathway
wishes to continue the partnership approach that has been so successful during
the roll-out of ALPS. Our approach to the pilot programme (see Sub-section
6.2) emphasises partnership and explains how we will prove to the various user
groups that we can meet their requirements with our solution. We will prove
our solution from three different viewpoints :
(a) Business process to ensure the solution supports all BA/POCL business
requirements.
(b) Service characteristics to prove our capability to provide quality services.
(c) Technical architecture to confirm that Pathway’s solution will support all
current and projected POCL infrastructure needs.
Sub-section 6.3 describes the objectives of the demonstrator phase and explains
how an agreed baseline will be established during contractual negotiations.
The operational trial phase is described in Sub-section 6.4, Pathway will prove
to BA and POCL that the risks in rolling out the end-to-end services are
understood and contained and show that the services provide the anticipated
fraud prevention and POCL support benefits. The response to the business
needs of BA and POCL is covered at Sub-section 6.5 - Pilot Programme Proving.
The outline PRINCE project plan contained in Sub-section 6.6 covers the period
between shortlisting and contract award. It identifies the roles and resources
needed to produce the deliverables for the agreed baseline needed to submit
financial proposals and then to refine them in the light of live user feedback.
The matrix of service components and proving mechanisms confirms that all
components are proved with regard to the technical, business practice and
service characteristics.
The section concludes with a Summary at Sub-section 6.7 and finally the
answers to the Specific Responses requested in the SSR.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
6.2 PROVING APPROACH
6.2.4 BACKGROUND
6.2.1.1 The pilot programme is about solution proving and the management of risk.
Pathway is focusing its own organisation on proving the low-risk nature of our
solution by providing firm evidence to BA/POCL of our capability. We are
planning to complete a comprehensive proving exercise to ensure that BA/POCL
and Pathway are satisfied that the services provided meet the business objectives
and needs of the various user groups.
6.2.1.2 Pathway will exploit the experience and success of its shareholders and principle
subcontractors in using prototyping and pilot implementations to prove our
solution and minimise risks for subsequent roll-out programmes. We will use
this experience and also that gained from other projects with similar
requirements to POCL and BA, to provide the baseline for Pathway’s proving
programme. Examples of relevant experience that applies is summarised below.
(See Annex 6 for further details).
Case Study : Relevant Overview :
Experience :
ALPS Counter ESNS Riposte-based system for POCL
Interface providing negative authorisation of benefit
Service payments, integrated with ECCO+ and APT
Roll-out functionality. Being rolled out to 1,500 post
offices within the M25 at an average of over
100 offices a week
An Post - PMS Riposte-based counter interface system with a
CounterAction Counter card-based positive authentication benefit
Interface payment system, OCR bill in-/out-payments,
Service automatic reconciliation and savings bank
TMS account transaction support. Uses touch screen
Roll-out technology and has been implemented at over
400 locations
ICL Singapore Counter Prototype using Riposte software being
Post Office Interface evaluated by the Singapore Post Office. The
prototype Service functionality includes a range of in-/out-
TMS payments, EPOS, cash and stock balancing and
interfaces to a number of peripherals and
mainframe systems
De la Rue AA CMS Manufacture and personalisation of 18 million
Project cards at a rate of 50,000 cards per day
Girobank Reconciliation I A five-month pilot for POCL, covering the
Girocheque Roll-out processing, reconciliation and settlement of all
reconciliation BA girocheques cashed at post offices. Piloted
pilot in Wales and now used countrywide
Girobank Visa call I CMS The establishment and management of a call
centre management centre dealing with the
I production and issue of cards to 300,000
I customers
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
Case Study : Relevant Overview :
Experience :
CHOTS - Roll-out Pilot implementation undertaken by ICL-led
competitive pilot consortium now rolled out into a large number
of Ministry of Defence buildings
6.2.2 PROVING PROCESS
6.2.2.1 The pilot programme is an essential and vital part of the procurement process.
It starts after the SSR shortlist and completes with final acceptance prior to
award of contract. It provides the means by which BA and POCL can be sure
that the Pathway solution is viable and that we are ready and able to roll out our
solution nationwide. Proof will be provided that we understand the business
requirements and can provide a socially and politically acceptable solution to a
diverse set of users and customers.
SERVICE
RISK
BASELINE
REDUCTION REFINEMENT
PROPOSED SOLUTION
Demonstrator Pate I
beep I REFERENCE I ppemonsraare
[AGREED SOLUTION
Operational Trial Phase
ste I SIMULATE i I LIVE TRIAL
ACCEPTED SOLUTION ¢
Fig. 1 - Proving Process
6.2.2.2 The Pathway proving process covers both the Demonstrator and Operational
Trial phases. We will use different techniques to prove aspects of our solution
in each phase. Any risks identified in our solution will be addressed, and
removed or contained as the proving progresses. We intend to agree baselines
with BA/POCL at each phase of solution development. This will ensure that all
parties understand the progress that is being made towards the final and
accepted solution,
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
i
SECTION 6 - PILOT PROGRAMME
6.2.2.3
6.2.2.4
6.2.2.5
6.2.2.6
6.2.2.7
6.2.2.8
6.2.2.9
Our proposed solution is based on the use of proven service components and
products. Each component has been selected on its ability to be tailored to the
specific BA and POCL requirements. The selection process was designed to
identify the ‘best of breed’ available. Components have been evaluated for their
ability to meet evolving needs and provide flexibility, functional scalability and
value for money over a protracted timescale. This proposed solution forms the
SSR shortlist milestone ‘proposal baseline’ and the baseline for the start of the
demonstrator phase.
The demonstrator phase will start with reference proving. This involves
providing documented evidence of our ability to provide services that are
acceptable to the various user groupings in environments similar to those
required by BA/POCL. Site visits by BA/POCL users, clients, and service
managers, as well as representatives of the Contracting Authorities will follow to
gain confirmation of our understanding of the requirement and to capture user
feedback on the overall acceptability of each service component.
The ergonomic and usability aspects of the counter interface are key to the
success of post office automation. We will use demonstrations to evaluate
potential hardware, software, documentation and training options. In order to
enable users to evaluate the practical implications of alternative hardware
configurations at the counter, we will establish the Pathway model post office.
Pathway will undertake prototyping of the counter applications to build on the
results of the demonstrations and gain detailed user feedback, acceptance and
‘buy-in’ of the interface functionality. This continuous refinement process will
result in an agreed solution, which will form the baseline for financial proposals
and the start of the operational trial phase.
Following contractual negotiations, the operational trial phase will concentrate
on end-to-end service proving and readiness for roll-out. We will use
simulation to prove our ability to handle the anticipated steady state end-to-end
service performance. During this exercise, we will simulate the impact on
counter transactions of exception conditions and disaster recovery.
The live trial is the final element of the solution refinement process. We will
use it to gain acceptance of our roll-out strategy and services by proving them in
an operational environment. Confirmation of our simulation predictions will
form part of the evaluation. We will use our build and test capability to prove
our complete system prior to the live trial.
The live trial will prove our roll-out procedures and services including training,
documentation and help desk support. The duration of the live trial will need
to be sufficient to prove reconciliation processes. We will use the feedback
obtained during this period to complete the refinement of our solution and
achieve final acceptance.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
6.2.2.10 As our solution develops throughout the proving process, risks identified by
BA/POCL and Pathway will be reduced and removed. Both set of risks will be
maintained on one register to aid the management of this process.
6.2.2.11 Risk management and baseline refinement form the framework within which the
pilot project will operate. We will manage the project using the PRINCE project
structure with Pathway directors on both the project board and Project
Assurance Team (PAT). We wish to invite representatives of BA/POCL to
attend project checkpoint meetings as members of the PAT (see Sub-section 6.6
for details). This will provide the risk management controls needed and the
visibility to BA/POCL of our management processes.
6.2.3 PROVING MODEL
6.2.3.1 To prove that all services and their components meet the BA and POCL business
requirements, that the required service levels can be met and that the system is
scaleable to meet the perceived demand, is complex. One reason for this
complexity is that the proving requirements support three different but
complementary views of the same solution. Pathway proposes to simplify the
evaluation by using different techniques to prove our solution from the
following three different ‘proving’ viewpoints (see also Fig. 2, Proving Model) :
(a) Business Process Driven, proving that the functionality provided supports
BA/POCL users, customers and clients business processes.
(b) Service Characteristic Driven, proving that the services meet BA/POCL
quality requirements for Service Level Agreements (SLAs).
(c) Technology Driven, providing the capability to deliver the performance
levels and functionality required now and in the future by the Contracting
Authorities.
INITIAL
BASELINE
—-tI SERVICE BUILD
[BUSINESS SUPPORT I [QUALITY SERVICEI {FUTURE PROOF
PROVING I “proving I I__ PROVING
Business > Service 7 Technology
I Proce — (characteristic a Srarer
Driven ~~. Driven “— Drives
REVISED
BASELINE
Fig. 2 - Proving Model
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ate
SECTION 6 - PILOT PROGRAMME
6.2.3.4
6.2.4
6.2.4.1
6.2.4.1.1
6.2.4.2
6.2.4.2.1
6.2.4.3
6.2.4.3.1
6.2.4.3.2
This model will be used throughout the pilot programme. Each phase of the
pilot programme will build on the baseline achieved during the previous phase.
Proving requires that the requirement is formally defined and that the solution
reflects that requirement. We will establish with BA/POCL a formal model of
the requirements for each viewpoint, which will be refined and expanded as
proving proceeds. The services we build during the pilot programme will be
measured for acceptance against these models. Our proving model includes
both the proving process and the refinement required to gain user acceptance.
Involving the various user groups in the business process proving is essential to
achieve user acceptance. To provide a low-risk solution that is value for money
requires us to prove our service quality to the BA/POCL service managers and
the future proof nature of our architecture to representatives of the Contracting
Authorities.
PROVING TECHNIQUES
OVERVIEW
We will use the following techniques during the proving process to demonstrate
all aspects of our capability as part of our solution development process. We
will start by illustrating our track record and demonstrating our current
capability. Feedback gained from working closely with BA/POCL users will
provide valuable input to our solution development process. Some aspects of
proving will involve reference to documentary evidence.
RESEARCH
Recently Pathway commissioned market research into card type acceptability.
This type of research will continue, as will our participation in events such as
the National Federation of Sub-Postmasters annual conference. Pathway will
arrange for research findings to be presented to BA and POCL.
REFERENCE
We will use documented evidence to show our track record in service provision,
project management, design, development, implementation and roll-out. Our
proposal includes relevant case studies in Annex 6. We will present additional
material on these and other relevant examples during the proving activity to
gain confirmation of their acceptability as proof of our capabilities.
We will organise visits to sites using comparable services, to allow us to confirm
that we have interpreted correctly the BA and POCL service requirement. We
will input feedback from these visits into our development programme. The
following agenda will apply to such visits :
1. A presentation to set the scope and purpose of the visit.
2. A demonstration of the end-to-end service in operation.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
3. A feedback session to identify the completeness of fit with BA and POCL
requirements and any issues.
4. Distribution of literature summarising what has been seen and its relevance.
6.2.4.4 MODELLING
6.2.4.4.1 We will use modelling to define the requirements baseline formally from the
three viewpoints identified earlier. Each model will cover end-to-end service
definitions, exception conditions and any steady state or roll-out considerations.
We will include any anticipated future requirements.
6.2.4.4.2 During the proving process, we will :
(a) Create the model using the appropriate software and tools.
(b) Present the models to BA/POCL to gain feedback to refine the model.
(c) Calibrate the model as development proceeds until user acceptance is
achieved.
6.2.4.5 MODEL POST OFFICE
6.2.4.5.1 Pathway will establish a model post office to provide a means of proving in a
realistic environment. We will demonstrate all counter interface options. ‘This
will include alternative hardware configurations and counter applications. It
will provide the opportunity to evaluate the impact of options on POCL users
and customers. Proving will include the ergonomics of the hardware
components and the usability of the Human Computer Interface (HCI).
6.2.4.5.2 We will create a modular and mobile office so that it can be established initially
at the Pathway office in Feltham and later moved to the BA/POCL premises in
Victoria if this is acceptable to BA and POCL. The model post office will
provide :
¢ Counter positions reflecting multiple- and single-counter situations
* Front- and back-office areas
* Access for POCL counter staff and customers
6.2.4.6 DEMONSTRATION
6.2.4.6.1 During the service development process, we will demonstrate components of
our solution to BA/POCL to gain feedback on their suitability. By the end of
each proving phase, we will have refined our solution and obtained from
BA/POCL confirmation of its acceptability.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 7 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
6.2.4.7 PROTOTYPING
6.2.4.7.1 Prototyping is an essential element of our development programme. It provides
the means of gaining user input into the development process to check options
and preferences based on their experience of the business practice. Their
acceptance and buy-in to the final solution is essential. We will use prototyping
sessions to :
* Ensure that we understand fully the business requirements and that the
counter interface meets these requirements
* Gain acceptance of the counter interface by counter staff
¢ Evaluate the security and fraud implications at the counter interface
6.2.4.8 AUDIT AND ASSURANCE
6.2.4.8.1 We will use quality reviews to provide firm evidence of our solutions
compliance by :
* Establishing compliance with international standards
* Demonstrating compliance with established development methodologies
* Demonstrating conformance with Pathway guidelines and standards
6.2.4.8.2 The Pathway Quality Management System defines our quality procedures and
principles, The Pathway Security Policy (see Annex 5) defines the security
measures that will be applied. We will audit our compliance to both during the
pilot programme using qualified internal and external auditors. We will present
the results of these audits to the BA/POCL PAT representative(s) to prove that :
* Security standards are in place and are being incorporated in the design
* Quality procedures are in place and being adhered to by the project
6.2.4.9 SIMULATION
6.2.4.9.1 There are elements of proving which can be undertaken only by the use of
simulation techniques. They include volumetric testing and the simulation of
interfaces that do not yet exist. We will use simulation to prove :
* End-to-end service performance
* Scalability of critical individual service components
* Potential for future enhancement
6.2.4.9.2 We will use a workload generator to simulate transaction data flows from
interfaces or other components. The generator will allow appropriate volumes
to be passed across the interface.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 8 of 46
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
a
SECTION 6 - PILOT PROGRAMME
6.2.4.10
6.2.4.10.1
6.2.5
6.2.5.1
6.2.5.2
6.2.5.3
6.2.5.4
6.2.5.5
LIVE TRIAL
We will use the live operational trial feedback to confirm and refine our solution
prior to roll-out. All system components will be trialed to ensure the
acceptability of end-to-end services in a live environment. The duration of the
trial needs to be sufficient to prove reconciliation services.
BUSINESS PROCESS PROVING
The main objective of business process proving is to establish that our system
provides user interactions that are seen by BA/POCL users, customers and clients
as being an improvement on existing services. We will develop user interfaces
that are intuitive and user-friendly. This can be achieved most effectively by
involving directly in the development process those who will use the system.
We will obtain user acceptance and ‘buy-in’ of our solution in steps. Initially,
we will present options for their evaluation. Once agreement as been reached,
we will develop the solution further so that ergonomic considerations can be
evaluated. Finally, the live trial will present an opportunity to evaluate the
impact in an operational environment.
Options that we ask users to evaluate will include touchscreen- versus keyboard-
driven counter applications, and menu-driven versus fast-track access to
frequently used user functions. Counter times are an important aspect of user
acceptability. We will use the model office environment to verify the impact of
our solution on counter transaction times. We will request assistance from the
POCL experts in this area so that we can gauge correctly the variations from
current practices.
Our model post office provides also the environment for evaluation by both
counter staff and customers. We will use the post office environment to gain
feedback and advice from as many sources as possible. We will ask BA/POCL to
provide as wide a range as possible of user and customer group representatives.
We have already obtained offers of assistance from voluntary organisations, such
as the Carers National Association, MENCAP, Help the Aged, SENSE and Age
Concern and we will ask them to provide representatives during the proving
exercise to gain feedback on the needs of these disadvantaged groups.
We will create business process models which define our understanding of the
BA and POCL business processes. Each model will define the transactions that
must be supported, the interactions between these transactions and any
exception conditions. We will review these models with BA/POCL to reach a
common understanding of the detailed business requirements against which to
validate our solution.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 9 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
6.2.5.6 The techniques we will use for business processes proving are :
Technique Used : Component Proved : Proving Objective :
Research CMS Confirmation of the
acceptability of card types and
formats
Reference CMS, PMS, OSS, Counter Verification of suitability of
Interface Service Pathway’s service capability.
Baseline establishment
Modelling CMS, PMS, OSS, Counter Provision of functional
Interface Service requirements baseline against
which options and alternatives
can be evaluated
Model post office Counter Interface Service Check of ergonomic
acceptability of hardware and
software options
Demonstrations CMS, PMS, OSS, Counter Acceptability of the user
Interface Service interfaces
Prototyping Counter Interface Service Assurance of user acceptance
of the functionality provided
Live Operational CMS, PMS, OSS, Counter Confirmation of readiness to
Trial Interface Service roll out acceptable solution
6.2.5.7 We are assuming that site visits to view similar operational services and
demonstrations will need representatives from the following user roles :
* POCL counter staff
* POCL Postmasters
* BA office staff
¢ BA financial managers
* POCL client representatives
* POCL or BA staff acting as, or selected actual benefit customers from various
ethnic and linguistic communities, and disadvantaged groups
¢ POCL staff acting as (or actual) Bill Payment customers
6.2.5.8 For any Counter Interface Service prototyping or ergonomic proving, we are
assuming that representatives of POCL counter staff and user groups will attend.
We assume that the business modelling discussions will take place with the
Contracting Authorities representatives.
6.2.5.9 By the end of the demonstrator phase, we will have produced and agreed a set
of major deliverables as follows :
(a) Documented and agreed Human Computer Interface (HCI) style guide
which identifies the style acceptable to the various user communities.
(b) Prototyped Counter Interface Service applications agreed with
representatives of the user community.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 10 of 46
OJEC Notice 94/$ 165-58937/EN Date: 08/06/95
6.2.5,10
6.2.6.1
6.2.6.2
6.2.6.3
6.2.6.4
6.2.6.5
(c) Business Process Model defining the agreed business process requirements
which defines the processes each user group will use.
(d) Counter interface hardware configuration and product descriptions.
By the end of the operational pilot trial, our solution will have been refined in
the light of operational experience. We will have gained acceptance of all
business process related services by proving :
¢ Our ability to provide a user-acceptable counter interface
¢ The ergonomic acceptability of our counter hardware
* Our readiness to roll out benefit payment, EPOS, automated payments and
local OSS applications to each post office
SERVICE CHARACTERISTICS PROVING
The main objective of service characteristics proving is to establish that we are
developing the right services with the right characteristics to meet the BA/POCL
requirements. We will work with the BA and POCL service managers to define
and develop services that are responsive to user needs during roll-out and steady
state operations. We will use the proving exercise to develop user support
services and validate the Service Level Agreements (SLAs).
User support services include training, documentation and help desk support.
We will prove the acceptability of our solution in these areas in steps. At the
start of the demonstrator phase, we will develop our understanding of each user
groups’ training needs through discussions with representatives of the group.
We will apply a similar principle to verifying user documentation needs, using in
this case document synopses rather than a training needs analysis to document
and achieve agreement.
We will demonstrate training and documentation options to confirm agreement
to the style and content required. By the start of the operational trial phase, we
will have developed the user training and documentation material ready for use
during the live trial stage. We will apply feedback from this operational use to
refine the material prior to achieving final acceptance.
We will discuss SLA requirements with the BA and POCL service managers to
ensure that our help desk and interface services meet current and anticipated
future charging mechanisms needs. We will model the responsiveness required
of these services and calibrate the model during the live trial.
During the demonstrator phase we will present to BA and POCL our
recommended roll-out approach, as described in Section 7 - Roll-Out and
Implementation. We will discuss this approach and agree how migration and
reconciliation will be handled by BA/POCL and Pathway during this period.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 11 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
wy
SECTION 6 - PILOT PROGRAMME
FUJ00098232
FUJ00098232
6.2.6.6 During the operational trial phase, we will prove our ability to implement our
roll-out strategy and deal with any contract or change management issues that
arise. We will implement change control on all baseline definitions at the start
of the demonstrator phase and this will be extended to cover all hardware,
software and service components prior to the live trial . We will incorporate
any refinements needed to the procedures as a result of feedback from the live
trial prior to final acceptance.
6.2.6.7 We will use the live trial to prove that the agreed migration and reconciliation
processes are effective and provide BA/POCL and Pathway with the confidence
to proceed to full roll-out.
6.2.6.8 The techniques we will use for service characteristics proving are :
Technique Used : Component Proved : Proving Objective :
Reference Training, documentation, I Verification of suitability of
help desk support, Pathway’s service capability.
reconciliation, roll-out, Baseline establishment
contract management,
TMS, OSS
Modelling Response times and Provision of service
interface requirements requirements baseline against
which SLAs can be evaluated
Demonstrations Training, help desk support I Acceptability of user interface
Live Trial Training, documentation, I Evaluation of readiness to roll
help desk support, out solution
reconciliation, roll-out,
contract management,
TMS, OSS
6.2.6.9 We are assuming that site visits to view similar operational services and
demonstrations will need representation from the following user roles :
« BA Service Manager
* POCL Service Manager
6.2.6.10 For user-related demonstrations, we are assuming that representatives of
BA/POCL users will attend. We assume that the service characteristics
modelling discussions will take place with the Contracting Authorities
representatives.
6.2.6.11 By the end of the demonstrator phase we will have produced and agreed a set of
major deliverables as follows :
(a) Training Needs Analysis that identifies the needs of the various user groups
where the analysis has been underwritten by the user.
(b) Synopsis for each type of user documentation underwritten by the users.
COMMERCIAL IN-CONFIDENCE Page: 12 of 46
Date: 08/06/95
Pathway Response to
OJEC Notice 94/S 165-58937/EN
SECTION 6 - PILOT PROGRAMME
6.2.6.12
6.2.7
6.2.7.1
6.2.7.2
6.2.7.3
(c) Service Characteristics Model which reflects the service requirements of
PMS, CMS, OSS, the Counter Interface Service and all interfaces to POCL
client systems as agreed with the Contracting Authorities.
(d) Roll-out plans agreed with BA/POCL service managers which identify how
the solution will be rolled out.
(e) Migration strategy plan agreed with BA/POCL service managers which
identifies how reconciliation will be accomplished during roll-out.
(f) Management, account and service-level reporting requirements agreed with
the Contracting Authorities which identify those reports that form the
reporting baseline between Pathway and BA/POCL service managers.
(g) Service monitoring plans agreed with BA/POCL service managers covering
all interfaces between Pathway-provided services and those provided by
BA/POCL.
By the end of the operational trial phase, we will have gained acceptance of all
support and interface services and agreement to our roll-out plan by proving
that :
¢ We have effective contract change management procedures
* We understand migration issues and have contained them
* Reconciliation can be achieved using current and new system components
* Our training is effective and gives the users the confidence they need to use
the system effectively
* Our installation co-ordination works well in the post office environments
chosen
TECHNICAL STRATEGY PROVING
The main objective of technical strategy proving is to establish that we have a
technical architecture that is viable now and in the future, and in particular that
it can support any new business activities undertaken by POCL at minimum risk.
It is important also that we can prove the capacity of the system to handle the
anticipated workload before roll-out.
We will prove our technical architecture in steps. We will model the various
architectural components by using discrete event-driven modelling. This kind of
technique is the industry standard for volumetric modelling of distributed
systems. Once this model has been agreed, we will place ‘Thermometers’ in key
software components during the demonstrator phase to calibrate the models as
the system is developed. We will use the models to validate end-to-end service
performance.
During the operational pilot phase, we will use a workload generator to simulate
the transaction volumes required to prove the scalability of critical individual
service components and the potential for future enhancement.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 13 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
a 3
SECTION 6 - PILOT PROGRAMME
6.2.7.4 We will use the workload generator also to simulate parts of the system that may
not exist during the demonstrator and operational trial phases. The generator
will allow transaction data flows to be simulated and passed to the other
components in the appropriate volumes.
6.2.7.5 There are a number of exception conditions for which we will produce plans for
agreement during the demonstrator phase. We will provide the fraud scenarios
against which we have included prevention mechanisms within our solution.
We will discuss these with BA/POCL and agree the fraud each mechanism is
intended to prevent. Similarly, we will produce fall-back, recovery and
contingency plans for agreement. These will identify the conditions that will
cause them to be invoked and the responsibilities of all parties.
6.2.7.6 We will conduct design-assurance reviews during the demonstrator phase to
establish the compliance of our solution with international standards. We will
demonstrate our compliance with Pathway development methodologies also
during this phase.
6.2.7.7 During both the demonstrator and the operational pilot phases, we will conduct
quality and security reviews against the policies detailed in Annex 2 and 5
respectively. We will use the reviews undertaken during the demonstrator
phase to prove to ourselves and BA/POCL representatives that we have
incorporated the security standards in our solution and that the quality
procedures are being applied. We will audit the use of both again during the
operational trial phase.
6.2.7.8 The techniques we will use for technical strategy proving are :
Technique Used : Component Proved : Proving Objective :
Reference Technical architecture Verification of suitability of
components architecture to support
BA/POCL requirements.
Confirmation that the
components proposed can be
enhanced in the future at
minimum risk,
Baseline establishment
Modelling Technical Architecture Provision of technical baseline
against which workload
predictions can be evaluated
Demonstrations Fraud scenarios, fall- Acceptability of exception-
back/recovery plans and condition handling
contingency plans
Simulation Missing components and I Scalability of Pathway solution
anticipated workload
transactions
Review Security and Quality Compliance with security and
quality policies
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 14 of 46
OJEC Notice 94/S 165-58937/EN_ Date: 08/06/95
SECTION 6 - PILOT PROGRAMME
6.2.7.9
6.2.7.10
6.2.7.11
6.2.8
6.2.8.1
6.2.8.2
6.2.8.3
We recommend that representatives of the Contracting Authorities are present
during technical architecture proving.
By the end of the demonstrator phase, we will have produced and agreed a set
of major deliverables as follows :
(a) Fraud scenarios which define the agreed fraud-prevention mechanisms
included in our solution and identify the fraud they are intended to prevent.
(b) Technical Architecture Model which specifies the workload characteristics
of each element of the system.
(c) Fall-back, recovery and contingency plans for the solution to be rolled out.
(d) Quality and security audit review reports which identify any non-
conformance and corrective actions,
By the end of the operational trial phase, we will have gained acceptance of our
technical architecture by proving that :
¢ We can meet the anticipated transaction volumes through end-to-end service
simulation
« We have included security procedures that provide acceptable fraud
prevention measures in our solution
* We have an acceptable fall-back and recovery plan
* Our contingency plans are acceptable
WORKING RELATIONSHIPS
To ensure that the proving process is successful and that we develop a low-risk
solution which meets BA/POCL requirements needs resources and commitment
from all the organisations involved. Pathway has established an organisational
structure, evolved from the one used during proposal production, to reflect and
support the requirement of the diverse groups.
Success during the proving process will depend to a great extent on the working
relationship developed between BA/POCL staff and the Pathway team.
Partnership within the bounds of the contractual obligations will minimise the
risk to all. Pathway recognises that BA/POCL staff have the in-depth
understanding of the requirement, the organisational cultures involved and the
POCL customer base.
The way that we see the working relationship building from the current
proposal production phase through to roll-out is indicated in Fig. 3 below.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 15 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SEP
SECTION 6 - PILOT PROGRAMME
6.2.8.4
6.2.8.5
6.2.8.6
PATHWAY CONTRACTING
MANAGEMENT AUTHORITIES
CONTROL MONITORING
ARCHITECTS Po PROPOSAL
ERS "I «PRODUCTION +S TEAM
a
DEVELOPERS DEMONSTRATOR IqBA/POCL, USERS, _I
INTEGRATORS "I ACTIVITIES CLIENTS &
I CUSTOMERS
——___,
OPERATIONAL _SYSTEM....
TRIAL ACTIVITIES MANAGERS
aia
? ROLL-OUT
ACTIVITIES
Fig. 3 - Working Relationships
The architects and designers who have developed our proposal solution will
form the nucleus of our design team for the demonstration and operational trial
phases. This team will be joined by development teams who will tailor our
solution to deliver the BA/POCL application functionality and by the integrators
who will be responsible for ensuring that these functional components combine
to provide the required end-to-end services for the live trial. They will receive
also the feedback from the trial so that lessons learnt can be included roll-out.
We will provide designers to develop training, documentation and help desk
support during the demonstrator activities. The involvement of representatives
of BA/POCL users, customers and clients in demonstrator activities has been
described earlier. Their involvement will provide the Contracting Authorities
team with visibility of Pathway activities during this period. We intend to
manage the pilot programme as a PRINCE project with a Project Board and
Project Assurance Team (PAT) consisting of Pathway directors (see Sub-section
6.6 for details).
Pathway recommends co-opting one or more members of the procurement team
to act as an User Assurance Co-ordinator in the Pathway PAT. Their role is to :
(a) Ensure that the detailed business practices and requirements of BA and POCL
users (in particular BA financial users and BA/POCL service management) are
supported by the Pathway solution.
(b) Monitor the way counter staff preferences for the ergonomics of the solution are
handled during demonstrations and prototyping activities.
(c) Observe and report on post office customer reactions to the service characteristics
during demonstrations in the model post office.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 16 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ne
SECTION 6 - PILOT PROGRAMME
6.2.8.7
6.2.8.8
6.2.8.9
6.2.9
6.2.9.1
6.2.9.2
6.2.9.3
6.3.
6.3.1
6.3.1.1
During the operational trial phase, we will include additional implementation
and support teams in our organisation. These will form the nucleus of those
teams needed for full roll-out after final acceptance. During the live trial we see
the need for in-depth involvement of the BA/POCL service managers.
During the pilot programme we would offer BA/POCL representation on the
Pathway PAT to:
(a) Ensure that all interface requirements have been interpreted correctly and
that our solution can handle the migration issues.
(b) Monitor the way training and documentation is received by users and the
way feedback is incorporated into the accepted versions.
(c) Observe and report on post office reactions to the support provided so that
maximum benefit can be gained from trial activities.
Pathway will work throughout the pilot programme with BA and POCL to
develop an effective working relationship and prove that Pathway has the
culture, capability and structure to provide a quality service throughout the life
of the contract.
RISK MANAGEMENT
Pathway has established a risk management process and a Risk Register. This
assigns each risk to the party best able to manage the risk. Once we are advised
of the Pathway risks on the BA/POCL Risk Register, we will match them to our
own and add any not previously identified. The Risk Register will evolve
during the programme as circumstances and requirements change.
The combined Risk Register will be one of the prime inputs to the demonstrator
phase. The activities planned during this phase cover proving of all services in a
component and an end-to-end manner. Specific activities to deal with risks
identified by BA and POCL can therefore be incorporated easily into our
proving.
Risks that can be resolved in the demonstrator phase will be closed only when
BA/POCL procurement management have signified the acceptability of the
proof.
DEMONSTRATOR PHASE
INTRODUCTION
The demonstrator phase forms the first part of the pilot programme. The main
aim of this phase is to ensure that our solution is viable, meets the BA/POCL
requirements and will be acceptable to its users.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 17 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
6.3.1.2 During the demonstrator phase, we will work with BA/POCL to identify,
eliminate and contain risks in the Pathway solution. We will prove to BA/
POCL that the Pathway solution satisfies their primary needs as specified in
Chapter 6.4.3 of the SSR using the techniques described in Sub-section 6.2.4 of
this proposal. By the end of the phase, we will have established the agreed
baselines on which to base our financial proposals.
6.3.2 DEMONSTRATION MODEL
6.3.2.1 Using our proving approach, the proving model for this phase becomes the one
shown in Fig. 4.
PROPOSAL
BASELINE
po~nenne-REEINEMENT I SERVICE COMPONED
es
“QUALITY SERVICE
PROVING
PROVING
Research *
Reference
Reference
‘Modelling,
Moda pos oer
Prong
AGREED
BASELINE
Fig. 4 - Proving Model
6.3.2.2 The proving techniques (see Sub-section 6.2.4) for business process proving (see
Sub-section 6.2.5), service characteristics proving (see Sub-section 6.2.6) and
technical strategy proving (see Sub-section 6.2.7) are as follows for the
demonstrator phase :
¢ Reference visits to similar operational services
* Research into user preferences
* Modelling of requirements from the business process, service and technology
viewpoints
¢ Demonstration of hardware and software options
* Model office illustration of counter interface interactions
¢ Prototyping of counter interface applications
* Design assurance activities
* Security and quality audits
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 18 of 46
OJEC Notice 94/S 165-58937/EN_ Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
6.3.3 DEMONSTRATOR PHASE CHECKPOINTS
6.3.3.1 The activities undertaken during this phase are described in Sub-section 6.6.
The agreement checkpoints for monitoring this phase are :
(a) Confirmation through reference visits that our proposed service
characteristics meet the overall BA/POCL requirement.
(b) Completion of the counter interface prototyping and HCI Style guide.
(c) Completion of all demonstration activities to confirm selection from options
available.
(d) Completed user Training Needs Analysis and documentation synopses.
(e) Reviewed roll-out strategy.
(f) Final demonstration.
6.3.3.2 We will formally present the following results from the demonstrator phase to
BA/POCL :
* Agreed solution, including reasons for selecting options
* Agreed baseline as represented by the business process, service characteristics
and technical architecture models
* Status of all risks on the Risk Register
¢ Agreed roll-out strategy
6.3.4 PROPOSAL BASELINE
6.3.4.1 The initial baseline for the demonstrator phase will be :
* Business Process definitions as included in the SSR and the Pathway proposal
Section 4
* Service characteristic definitions as included in the SSR and the Pathway
proposal Section 5 and 7
* Technical architecture definitions as included in the Pathway proposal
Section 4
* BA/POCL Risk Register
* Pathway Risk Register
6.3.4.2 We will use this baseline to create the various models which will be proved,
calibrated and refined as the proving continues.
6.3.5 AGREED BASELINE
6.3.5.1 The agreed baseline at the end of the demonstrator phase will be based on :
* Business Process model
* Service Characteristic model
* Technical Architecture model
* Training Needs Analysis
* User documentation synopses
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 19 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 6 - PILOT PROGRAMME
6.3.5.2
6.4,
6.4.1
6.4.1.1
6.4.1.2
6.4.1.3
6.4.2
6.4.2.1
¢ Roll-out strategy
* BA/POCL Risk Register
* Pathway Risk Register
We will use this baseline as input to the creation of SLAs and the Pathway
financial proposal.
OPERATIONAL TRIAL PHASE
INTRODUCTION
The operational trial phase forms the second part of the pilot programme. The
main aim of this phase is to establish Pathways readiness for roll-out.
By the end of the demonstrator phase, Pathway will have proved to BA and
POCL that our solution meets all current requirements, is low-risk and provides
a forward path for any new requirements. We will have validated our
understanding of the user requirements, have prototyped the user counter
interface and have proved that the equipment we propose will operate in post
office environments. The operational trial phase builds on this understanding
and the working relationship that will have been built up with BA, POCL, and
the various user groups.
During the operational trial phase, Pathway will complete the development,
integration and testing of service components, Phase prior to the start of the
live trial, we will conduct formal testing against the requirement models agreed
during the demonstrator.
OPERATIONAL TRIAL MODEL
Using our proving approach described in Sub-section 6.2, the proving model for
this phase becomes the one shown in Fig. 5.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 20 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
6.4.2.2
6.4.2.3
6.4.3
6.4.3.1
AGREED
BASELINE
I SERVICE BUILD I
i ee 7
FUTURE PROOF
PROVING
ee Semlation
Live til
ACCEPTED
BASELINE,
Fig.5 - Proving Model
The proving techniques(see Sub-section 6.2.4) for business process proving (see
Sub-section 6.2.5), service characteristics proving (see Sub-section 6.2.6) and
technical strategy proving (see Sub-section 6.2.7) in the operational trail phase
are:
* Simulation of end-to-end services to prove scalability to anticipated volumes
* Live trial to establish the acceptability of all service
The initial baseline for this phase is the final baseline established at the end of
the demonstrator phase.
OPERATIONAL TRIAL PHASE CHECKPOINTS
The activities we will undertake during this phase are described in Sub-section
6.6. The acceptance checkpoints for monitoring this phase are :
(a) Initiation of live trial to exercise roll-out procedures and services.
(b) Business process, service characteristics and technical architecture models
representing BA/POCL requirements.
(c) Training courses and user documentation.
(d) Roll-out plan.
(e) End-to-end service simulation of anticipated transaction volumes .
(f) Change management procedures.
(g) Contract management procedures.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 21 of 46
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
6.4.3.2
6.4.3.3
6.4.3.4
6.4.4
6.4.4.1
6.4.5
6.4.5.1
The SSR identifies the period from January to May 1996 as the time-window
for the operational trial phase. Pathway will discuss the exact nature of the
operational trial phase of the pilot programme with BA and POCL during Stage
3 Draft Contract Negotiations. However, Pathway’s proposed schedule for the
operational trail phase :
+ Allows a month for planning the live trial
* Rolls out to a limited number of post offices starting in February
* Contains a three-month period of live usage from February to May 1996
* Involves reconciliation of Cash Accounts during the three-month period
* Simulates the CAPS interface, if necessary
This period will be sufficient to allow the BA/POCL evaluation team to confirm
that our services have the characteristics required for the PFI contract and that
the IT infrastructure meets the requirements of both BA and POCL.
During the demonstrator phase, the BA/POCL evaluation team will have had the
opportunity to work with the Pathway team. Joint planning of the live trial will
show the quality of Pathways project and service management. It will provide
also the opportunity for BA/POCL to see the quality of the Pathway roll-out
standards and procedures.
CONTRACTUAL BASELINE
We will establish formal change control at the beginning of the demonstrator
phase. We will deal formally with all changes required as a result of proving,
including end-to-end system simulation and the live trial during the operational
trial phase. This will give us the opportunity to resolve any issues with the
Pathway change control procedures and exercise the interface between these and
any used by BA/POCL.
FINAL ACCEPTANCE
Deliverables will be agreed during the demonstrator phase and accepted by the
end of the pilot programme. Agreement to final acceptance will represent the
point at which the contract can be issued and roll-out started. We will agree the
format and content of this acceptance activity during the contract negotiation
stage but we anticipate that it will involve the production and presentation of a
report of :
(a) The simulation and modelling activities, indicating any volumetric or
interface issues that arose, how they were tackled and their current status .
(b) The live trial, indicating any roll-out issues with SLAs or planning that were
raised and the state of their resolution.
(c) The status of user group agreement to the acceptability of user interfaces.
(d) The agreed roll-out plan.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 22 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
6.4.5.2 Final acceptance would then be achieved after discussion and acceptance of the
report.
6.5. PILOT PROGRAMME PROVING
6.3.1 INTRODUCTION
6.5.1.1 This section addresses Chapter 6.4 of the SSR which details the pilot programme
requirements. It summarises how the Pathway proposal has addressed the
requirement for the supplier to prove capability during the pilot programme.
The tables that follow list the requirements stated in the SSR and provide a
description of the proving technique we will use during either or both the
demonstrator or operational pilot phases
6.5.2 OVERALL PRIME CONTRACTOR CAPABILITY
6.5.2.1 We will manage the pilot programme proving as a PRINCE-based project. All
Pathway directors will be involved on either the Project Board or the PAT. We
invite BA/POCL to provide representatives for the PAT. This will allow
BA/POCL to evaluate our management processes. We will use reference to
prove our overall capabilities during the demonstrator phase with direct
observation being possible during the live trial. We will include representatives
of the Contracting Authorities in all proving of our capabilities as a prime
contractor, as identified below :
Summary of SSR Proving Techniques Phase
Evaluation Criteria
(a) Project and service Reference visits Demonstrator/
management PAT activities Operational trial
Project management
Live trial service management
(b) Quality of standards I Reference visits including Camelot I Demonstrator/
and procedures Security and quality audits Operational trial
Live trial procedures
(c) Understanding of Reference experience including Demonstrator
business and of service ESNS and girocheque
requirements reconciliation
Business process modelling
Service characteristics modelling
(d) Cultural and Reference experience of ALPS roll- I Demonstrator/
commercial compatibility I out Operational trial
to work within both the I PAT activities
BA and POCL business Demonstrations
environment Prototyping
Reviews
(e) Flexibility and Reference experience of ALPS roll- I Demonstrator/
responsiveness to cope out and Camelot Operational trial
with change and fast roll- I Live trial roll-out
out
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE
Page: 23 of 46
Date: 08/06/95
Summary of SSR Proving Techniques Phase
Evaluation Criteria
(f) Technical and Reference visits to development, Demonstrator/
logistical competence build and test capabilities Operational trial
Technical Architecture Model
I Roll-out implementation
(g) Speed of Reference experience of ALPS and I Demonstrator/
implementation Camelot roll-outs Operational trial
Roll-out strategy j
Live trial roll-out I
6.5.3 POCL PRIME NEEDS
6.5.3.1 POCL wishes to satisfy itself that Pathway can provide a flexible and usable,
quality set of services that provides compatibility with current systems, can be
reconciled at various levels and provides an acceptable migration path. During
the demonstrator phase we will cover these issues in the main by reference,
prototyping, modelling and simulation. We will extend the proof during the
operational trial phase to provide the end-to-end proof needed to achieve
acceptance of the various services.
Summary of SSR Proving Techniques Phase
Evaluation Criteria
(a) Flexible solution Demonstration of An Post and Demonstrator
Singapore counter applications
including stock control, additional
in/out payment applications,
support systems and reporting
Counter application prototyping
Security audit
Technical Architecture Model
(b) Capability of being Demonstration of hardware and Demonstrator/
introduced at all post software options in model post Operational Trial
offices office
Live trial
(c) Secure, accurate and Reference to Girobank girocheque I Demonstrator/
auditable accounting and I reconciliation service Operational Trial
reconciliation OSS business process model
Service characteristics modelling
Live trial
(d) Compatibility with Technical architecture modelling Demonstrator/
existing systems strategy I Service characteristics modelling Operational Trial
and interfaces Simulation
(e) Service which is easily I Direct user experience of the ALPS I Demonstrator/
understood by counter ESNS application Prototyping of Operational Trial
clerks counter applications
Demonstrations
Training
Live trial
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 24 of 46
OJEC Notice 94/S 165-58937/EN
Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
6.5.4
6.5.4.1
Summary of SSR Proving Techniques Phase
Evaluation Criteria
(f) Improved quality of Reference visit to An Post post Demonstrator/
service to clients and office Operational Trial
customers Experience of ALPS
implementation
Prototyping
Model office demonstrations
Live trial
(g) Migration of existing I Reference to girocheque Demonstrator/
systems with minimum reconciliation Operational Trial
disruption Migration plan
Roll-out strategy
Live trial roll-out
BENEFIT AGENCY PRIME NEEDS
For the Benefit Agency, the emphasis during proving is on the end-to-end
Benefit Payment Service and card issue, their impact on reducing fraud and
providing benefit reconciliation and their suitability as a method of migrating
from existing paper-based encashments. Again the developments undertaken
during the demonstrator phase will be extended into an end-to-end service.
Summary of SSR Proving Techniques Phase
Evaluation Criteria
(a) Reliable and consistent I Reference to An Post end-to-end Demonstrator/
‘end-to-end’ service
service
Business process modelling
Service characteristics modelling
Live trial
Operational trial
(b) Large scale card issue I Reference visit to De La Rue Demonstrator
and management card production and issue
operation facility
Reference visit to A&L card
management service
(c) Migration to card- Reference to An Post post office Demonstrator
based service Migration planning
(d) Proven methods for Research Demonstrator/
fraud reduction that are Fraud scenarios Operational trial
practical and politically Security Audit
and publicly acceptable Live trial
(e) Secure, accurate and
auditable accounting.
Reference to Girobank girocheque
reconciliation service
OSS business process model
Service characteristics modelling
Live trial
Demonstrator/
Operational trial
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE
Page: 25 of 46
Date: 08/06/95
FUJ00098232
FUJ00098232
ei
SECTION 6 -
6.5.5.1
6.5.6
6.5.6.1
CUSTOMER / CLERK NEEDS
The need to assess the acceptability for POCL counter staff and customers is the
driver for undertaking prototyping and demonstrations during the demonstrator
phase. Having achieved agreement to the counter interface, the operational trial
phase will confirm the acceptability and allow real life proving. We will use this
proving to ensure that the system is focused on supporting the counter staff in
their every-day activities and that customers receive the quality of service
expected.
Summary of SSR Proving Techniques Phase
I Evaluation Criteria
(a) Post office space and I Reference to ALPS roll-out Demonstrator/
environmental constraints I Demonstration of hardware and Operational Trial
software options in model post
office
Live trial
(b) Payment method Research Demonstrator/
acceptable to all kinds of I Reference to ESNS system and Operational Trial
customer Singapore post office applications
Model post office demonstrations
to elderly, disable and non English
speaking representatives
Liye trial
(c) Service can cope with I Business process modelling Demonstrator
exception conditions Model office demonstrations
(d) Contingency in the Reference to An Post Demonstrator
case of full or partial system
system failures Fall-back/recovery planning
Contingency planning
Model office demonstrations.
(e) Migration options Reference to An Post post office Demonstrator
acceptable to customers Migration planning
Model office demonstrations
TRAINING AND DOCUMENTATION
Both BA and POCL need to satisfy themselves before roll-out commences that
the training and documentation provided with the system meets the needs of the
various user groups. During the demonstrator phase, we will prove our
capabilities by reference, training needs analysis and demonstration. During the
live operational trial we will extend the proving by undertaking training courses
and evaluating their effectiveness.
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE Page: 26 of 46
Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME,
Summary of SSR Proving Techniques Phase
Evaluation Criteria
(a) Training capability Reference to Camelot training Demonstrator/
programme
Demonstration of training
techniques and options
Training needs analysis
Liye trial training
Operational trial
(b) Quality and standard
of documentation
Reference to Camelot
documentation
Demonstration of options
Documentation synopses
Live trial usage
Demonstrator
Operational trial
(c) Documentation of the
service for users, counter
Reference to Camelot
documentation
Demonstrator/
Operational trial
clerks and staff Live trial usage
(d) Ability to integrate Demonstration of options Demonstrator/
with existing systems and I Documentation synopses Operational trial
documentation Live trial usage
6.5.7 SERVICE DELIVERY
6.5.7.1 Service delivery proving during the demonstrator phase will occur in parallel
with producing SLAs. We will ensure that the scope and completeness of each
service and its interfaces are modelled and reflect the SLAs. Live trial proving
will calibrate our service characteristics models.
Summary of SSR Proving Techniques Phase
Evaluation Criteria
(a) Operational services Business process modelling Demonstrator
meet the full functional Service characteristics modelling
requirement
(b) Roll-out and support I Roll-out strategy Demonstrator/
services are Service characteristics modelling Operational trial
comprehensive and meet I Simulation
the availability and Live trials
responsiveness
requirements
(c) Effective project Project planning Demonstrator/
management and contract I Change control procedures Operational trial
management procedures I Contract management and usage
exist procedures and usage
Live trial service
(d) Contingency, fall-back I Fall-back/recovery planning Demonstrator
and recovery plans exist _I Contingency planning
{e) Interfaces to PAS, Service characteristics modelling Demonstrator/
CAPS and POCL systems I End-to-end service simulation Operational trial
are accurate and Live trial usage
auditable.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 27 of 46
OJEC Notice 94/S 165-58937/EN
Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
Summary of SSR Proving Techniques Phase
Evaluation Criteria
(f) Procedures exist for Demonstration of procedures and I Demonstrator
developing future mechanisms used for developing
services, BA/POCL services
(g) Commitment to Quality audits Demonstrator/
Quality Assurance Operational trial
FUJ00098232
FUJ00098232
6.5.8 IT INFRASTRUCTURE
6.5.8.1 IT infrastructure proving is about ensuring that our solution is future-proofed,
that is it can be extended over a period of time, that new products can be
introduced and technology improvements intercepted.
Summary of SSR Proving Techniques Phase
Evaluation Criteria
(a) Technology has Technical architecture modelling Demonstrator
capability to cope with Technical papers
increased volumes or Demonstrations
functionality
(b) Solution adheres to Product descriptions Demonstrator
industry and health & Technical architecture modelling
safety standards and
compatible with IS/IT
strategies
(c) IT infrastructure can Demonstrations Demonstrator
handle technology refresh
without disruption
(d) Appropriate security I Security audit Demonstrator
exists
(e) Workable Configuration management Demonstrator/
configuration procedures Operational trial
management exists Live trial
(f) Data integrity and Technical architecture modelling I Demonstrator
resilience measures have I Technical papers
been included
6.5.8.2 Pathway will present to BA/POCL options which represent value for money.
We will evaluate any changes agreed with BA/POCL during the pilot programme
for their commercial and financial impact.
6.6. PILOT PROJECT PLANS
6.6.1 INTRODUCTION
6.6.1.1 The plan outlined in this Sub-section covers the entire pilot programme. The
timetable we are using is that described in Chapter 9 of the SSR where a
calendar-related version is given. This identifies the following :
* July to November 1995 for the demonstrator phase
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE Page: 28 of 46
Date: 08/06/95
SECTION 6 - PILOT PROGRAMME
6.6.1.2
6.6.1.3
6.6.2
6.6.2.1
* January to May 1996 for the operational trial phase
We will discuss the implications of these dates with BA/POCL and adjust our
plan in the light of agreement reached.
Our plan describes the stages into which we have divided the work. It identifies
checkpoints within the plan at which we will conduct management reviews with
BA/POCL to confirm progress. It includes a description of deliverables and
when they will be accepted, and identifies the resource types needed to develop
them. We will need the involvement of BA/POCL users, customers and clients
during the programme. The plan summarises the requirements identified in
earlier Sub-sections.
MANAGEMENT STRUCTURE
We will manage the pilot programme as a PRINCE project with a Project Board
and Project Assurance Team (PAT). The project will report to a management
committee consisting of the Pathway Managing Director, the Business
Development Director and the Financial and Commercial Director. All the
Pathway directors have roles within the project reporting structure as shown in
Fig. 6.
SHAREHOLDERS BOARD
— .
Managing Director
Business Development Director
Commercial & Financial Director
“PROJECT BOARD
Programme Director Operations Director Technical Director I
I
(Executive) (Senior User) (enior Technical) I
i
PROJECT MANAGEMENT
PROJECT ASSURANCE TEAM
Financial Director Representative(s) Management Director
Business Assurance (User Assurance (Technical Assurance
Co-ordinazor) Co-ordinator) Co-ordinator)
‘Commercial & Evaluation Team [Quality & Risk
Fig. 6 Project Management Structure
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 29 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 -
6.6.2.2 As discussed earlier, Pathway invites representatives of BA and POCL to act as
User Assurance Co-ordinators to ensure that all user-related issues are raised and
dealt with in a timely fashion. The responsibilities allocated to each role are:
Pathway PRINCE Role : Pilot Programme Responsibility :
Director :
Programme Executive To co-ordinate all aspects of the proving
Director programme
Operations Senior User To ensure that the services are developed
Director that will be rolled out after contract award
Technical Senior Technical I To ensure that the integrity of the technical
Director Representative solution is maintained during the
development process
Quality & Risk I Technical To ensure that all risks identified are
Director Assurance Co- addressed and removed or contained
ordinator
Finance and Business To ensure that any contractual and cost
Commercial Assurance Co- implications are identified and addressed as
Director ordinator the programme proceeds
BA/POCL User assurance To ensure that any user related issues are
Representatives I Co-ordinator identified and addressed
6.6.1.4 We will conduct the pilot programme in three phases. Each will continue
throughout the programme and is targeted at a different proving viewpoint as
follows :
* Stage 1 covers Business Process proving
* Stage 2 covers Service Characteristics proving
¢ Stage 3 covers Technical Strategy proving
6.6.1.5 The stage managers will have access to the specialist resources needed to
conduct the proving from their particular viewpoint and they can be appointed
for each stage.
6.6.3 DELIVERABLES
6.6.3.1 During the pilot programme deliverable products will be produced for
agreement with BA and POCL. These deliverables will form the following
baselines :
* Proposal baseline - start of the demonstrator phase
* Agreed solution baseline - at the end of the demonstrator phase
* Accepted service baseline - at the end of the operational pilot
6.6.3.2 The deliverables for each stage, which form part of the agreed and accepted
baselines, are given below.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 30 of 46
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
h >
SECTION 6 - PILOT PROGRAMME
6.6.3.2 BUSINESS PROCESS DELIVERABLES
Deliverable : Description of Content : Acceptance Point :
HCI Style Guide Identifies the style acceptable Demonstrator phase
to users
Prototyped Counter Counter application Demonstrator phase
Interface Service functionality
Business Process Model Business requirements Demonstrator phase
definition
Counter interface Selected counter hardware Demonstrator phase
hardware configuration
Counter Interface Service I Counter application Operational pilot
functionality including Benefit I phase
Payment, EPOS and automated
payments
Card Management Service I Card management and Operational pilot
production functionality phase
Payment Management Benefit Payment functionality I Operational pilot
Service phase
Operational Support Local OSS functionality Operational pilot
Service phase
6.6.3.3 SERVICE CHARACTERISTICS DELIVERABLES
Deliverable : Description of Content: Acceptance Point :
Training Needs Analysis User training requirements Demonstrator phase
User documentation User documentation definition I Demonstrator phase
synopses
Service Characteristics Service characteristics Demonstrator phase
Model requirement definition
Roll-out plans Plan for roll-out of services Demonstrator phase
Migration strategy plan Plan for handling migration Demonstrator phase
issues during roll-out
MIS Reporting Management, accounting and I Demonstrator phase
service level reporting
requirements
Service monitoring plans I Definition of all interfaces Demonstrator phase
between Pathway and
BA/POCL provided services
Support services TMS and central OSS functions I Demonstrator phase
Transaction Management I Transaction management Operational pilot
Service functionality phase
Operational Support Central operational support Operational pilot
Service functionality phase
Help desks CMS, PMS, TMS and OSS Operational pilot
support phase
User Training Courses for all user groups Operational pilot
phase
User documentation Documentation to support Operational pilot
users phase
Change Management Procedures to control changes _I Operational pilot
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 31 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
Deliverable : Description of Content : Acceptance Point :
Procedures to services phase
Roll-out procedures Procedures to be followed Operational pilot
during roll-out phase
6.6.3.4 TECHNICAL ARCHITECTURE DELIVERABLES
Deliverable : Description of Content : Acceptance Point :
Fraud scenarios Agreed fraud prevention Demonstrator phase
mechanisms
Technical Architecture Definition of workload Demonstrator phase
Model characteristics of architectural
components
Fall-back and recovery Plans to handle exception Demonstrator phase
plans conditions
Contingency plans Plans to handle contingency Demonstrator phase
conditions
Audit reviews Reports on quality and security I Demonstrator and
audits operational trial
phases
Fall-back and recovery Proof of fall-back and recovery I Operational Trial
simulation plans phase
Workload simulation Proof of capability to process Operational Trial
anticipated workload phase
6.6.4 PILOT PROJECT
6.6.4.1 We will appoint project and stage managers, produce deliverable products and
manage activities using checkpoint reporting. We will produce a PRINCE
project plan and stage plans based on the descriptions, definitions and outline
plans given in our proposal.
6.6.4.2 The overall schedule on which we have based our activities for the pilot
programme is given below. It covers the period from submission of the Pathway
proposal to BA/POCL and ends at the point where final acceptance has been
achieved of the services which are to be rolled out. Our plan covers the
activities that will occur during procurement stages :
* Stage 3 Contract Negotiation/Pilot Commencement
* Stage 4 Evaluation and Selection
¢ Stage 5 Operational Trials
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 32 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
% Yoda
SECTION 6 - PILOT PROGRAMME
1995, 1996
Task Name rt [atre Tatrs [ars [ats Tare [ars [otra
Issue SSR @ 13/04
Proposal @ 08/06
Demonstrator Phase a
I ‘Operational Trial Phase
[Pitot Programme {GReeeORAREOTETES
(1) Business process proving Eze
(2) Service characteristics proving ——
[Seen as]
(3) Technical architecture proving
Reference visits complete @ 18/08
Prototyping complete 13/10
I Final demonstration @ 2710
I Ready for live trial I @ 02/02
Fig. 6 - Project Schedule
6.6.4.3 The schedule identifies the key activities we will undertake during the pilot
project and the key checkpoints, which are :
(a) Completion of reference visits to see similar systems in operation, which is
the point at which we will confirm that our proposal solution is well-
founded and can be developed to provide the services required by
BA/POCL.
(b) Completion of Counter Interface Service prototyping activities, which is the
point at which we will have achieved user buy-in to our counter
functionality and an agreed HCI format.
(c) Final demonstration at the end of the demonstrator phase, which is the
point at which we have an agreed low-risk solution to BA/POCL
requirements.
(d) Start of live trial activity, which is the point at which we need to start an
initial trial to check procedures, migration issues and reconciliation
implications,
6.6.5 STAGE 1 BUSINESS PROCESS PROVING
6.6.5.1 Stage 1 is about providing a set of user services which enhance the business
process support provided to BA and POCL users, customers and clients. The
key user interface is at the post office counter. Prototyping and demonstrations
are the key activities we will use to understand the user requirements and
achieve their acceptance of the solution we develop.
6.6.5.2 The schedule given below for Stage 1 identifies the key activities we will
undertake during the demonstrator and operational trial phases.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 33 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
fy
SECTION 6 - PILOT PROGRAMME
6.6.5.3
6.6.6
6.6.6.1
6.6.6.2
Task Name.
1995
1996
atrt Tatr2 [airs [atr4
[or2 [ars] ar4
Demonstration
Operational Trial
(1) Business process proving
Reference proving
Business Process Modelling
Ti
I ‘Completion of BPM @ 29/09
I Prototyping =
Completion of Prototyping @ 13/10
Demonstrations / Model Office ES
Completion of demonstrations © 27/10
Live Trial
@ 26/04
I ‘Completion of Live Trial
Fig. 7 - Stage 1 Schedule
The schedule identifies the following key checkpoints during the stage 1 :
(a) Completion of demonstration activities, which is the point at which we have
an agreed counter hardware configuration selected from the options
presented.
(b) Completion of the business process model which is the point at which we
have an agreed definition of the business processes to be supported.
(c) Completion of the live trial, which is the point at which we will have an
accepted definition of business process and user services providing support
for them.
STAGE 2 SERVICE CHARACTERISTICS PROVING
Stage 2 is about providing the set of support services which enable BA/POCL
users, customers and clients to feel confident in their use the services provided.
The key elements of this level of confidence are the quality of the training and
help desk support. We will involve users from the requirements confirmation
stage to ensure that quality services are developed.
The schedule given below for Stage 2 identifies the key activities we will
undertake during the demonstrator and operational trial phases.
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE Page: 34 of 46
Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
6.6.6.3
6.6.7
6.6.7.1
6.6.7.2
1995 1996
‘Task Name ari Tar2[atrs [ar4 Tartare [ ars] ars
Demonstration Eas
I Operational Trial ee I
la Service characteristics proving ae
Reference proving Ba
Service modelling as
Completion of service model © 29/09
Training Needs Analysis I
I Completion of TNA @ 15/09
I Demonstrations ea
I Live Trial ae
I Review of live training 08/03
I___Review of Live rol-out . @ 15/03
Fig. 8 - Stage 2 Schedule
The schedule identifies the following key checkpoints during stage 2 :
(a) Completion of training needs analysis and documentation synopses which is
that point at which we have an agreed definition of all user requirements.
(b) Completion of the service characteristics model which is the point at which
we have an agreed definition of the service and interface requirements.
(c) Completion of the review of our roll-out strategy, which is the point at
which we will have an accepted plan for the live trial roll-out.
(d) Completion of the review following live trial training, which is the point at
which we have an accepted set of training material and user documentation.
(e) Completion of the review following live trial roll-out, which is the point at
which we have an accepted set of roll-out procedures and plans.
STAGE 3 TECHNICAL ARCHITECTURE PROVING
Stage 3 is about proving that our solution has the architectural characteristics
required to support the anticipated BA/POCL workload and is capable of cost
effective future enhancement. We will use modelling and simulation to prove
this level of flexibility.
The schedule given below for Stage 3 identifies the key activities we will
undertake during the demonstrator and operational trial phases.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 35 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
I 1995 1996
Task Name Qtr [are [ars] ara [ari [a2 [ars [air
[Demonstration Co
I Operational Trial Free]
(8) Technical architecture proving ay
Reference proving Pe] I
Technical architecture modelling fa]
Completion of technical model © 29/09
Simulation of system components B
Security & quality audits
End-to-end simulation
Completion of audits
‘Completion of end-to-end simulation
Fig, 9 - Stage 3 Schedule
6..6.7.3 The schedule identifies the following key checkpoints during stage 3 :
(a) Completion of the technical architecture model which is the point at which
we have an agreed definition of the system performance characteristics.
(b) Completion of the end-to-end service simulation activities, which is the
point at which we will have proved our solution can handle the anticipated
workload.
(c) Completion of security and quality audits.
6.6.8 RESOURCING
6.6.8.1 We will vary the resourcing during the pilot project depending on the phase
being supported at the time. The pilot programme management resources will
remain constant. Other teams within the Pathway organisation, each belonging
to its own directorate, will provide resources and deliverables during the
proving process. The Pathway resourcing profile for the pilot programme is :
Project and Stage Resource Type Resource Source
Pilot Project Project/stage Programme Directorate
management
Planning
Administration
BA/POCL Liaison
Business Practice Modelers Technical Directorate
Designers/
Developers
Testers
Integrators
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 36 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
Project and Stage Resource Type Resource Source
Service Characteristics Modelers Operations Directorate
Trainers
Technical authors
Help desk staff
Installation specialists
System managers
Technical Architecture Modelers Technical Directorate
Architects
Security consultants
Quality consultants
Hacking specialists
Change control
consultants
6.6.3.2 We will seek assistance also from voluntary organisation representatives who
can advise on specialist customer requirements. The Carers National
Association, MENCAP, Help the Aged, SENSE, and Age Concern have all
offered assistance to Pathway in this area.
6.6.9 RESOURCE DEPENDENCIES
6.6.9.1 During the prototyping and demonstrating activities we invite involvement from
representatives of as many of the user and customer groups as practicable. The
closer we can work with these representatives the more acceptable our solution
will become. We will need representatives of the following groups during the
demonstrator phase :
¢ BA staff and financial users
¢ POCL counter staff, Postmasters
* POCL users, customers and clients
* Disadvantaged groups
* Ethnic minorities
6.6.9.2 We will arrange activities involving these resources to make maximum use of
their time. Prototyping and demonstration, in particular, can take place either
on Pathway premises in Feltham or in the procurement team accommodation in
Terminal House, Victoria.
6.6.9.3 Pathway proposes a three-month period of live trial running during the
operational trial phase. This requires a similar commitment from the various
user groups. The live trial would be conducted on POCL premises.
6.6.9.4 The resource dependencies on BA and POCL during the pilot programme are
summarised below :
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 37 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
-
SECTION 6 - PILOT PROGRAMME
6.6.10
6.6.7.1
Proving Stage
Requirement
Resource Type
Business Process Proving
Reference site visits
BA/POCL users, customer,
clients
Demonstrations BA/POCL users, customer,
clients
Prototyping BA/POCL users
Business process modelling I BA/POCL users
support
Reviews Contracting Authorities
representatives
Service Characteristics Reference site visits BA/POCL service
Proving managers
Service characteristics BA/POCL service
I modelling support managers
Discussion on training BA/POCL users
needs
Discussion on BA/POCL users
documentation needs
Training course attendance I BA/POCL users
I Reviews Contracting Authorities
representatives
Technical Architecture Reference site visits Contracting Authorities
Proving representatives
Simulation support Contracting Authorities
representatives
Reviews Contracting Authorities
representatives
COVERAGE MATRIX
The following matrix identifies the service elements that will be demonstrated
during the pilot programme. It contains references to the descriptions of each
service element in sections 4,5 and 7 of our proposal. Where appropriate, the
organisation that will provide supplementary evidence in the form of reference
site visits to other like services has been indicated.
Service Service Reference Principal Proposal
Proved Component Visits To Section Reference
Demonstrated
Benefit Card Production I De La Rue 44.4.4 & 4.4.4.5
Payment & Distribution
Service
CMS A&L 4.2.7 & 4.4.3
PMS. Girobank 4.2.6 & 4.4.5
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 38 of 46
OJEC Notice 94/S 165-58937/EN
Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
Service Service Reference Principal Proposal
Proved Component Visits To Section Reference
Demonstrated
POCL TMS An Post 4.2.8 & 4.3.4
Strategic
Infrastructure
Counter Interface_I An Post 4.2.9 & 4.3.3
OSS Girobank/An 4.2.10 & 4.3.6
Post
Support Pathway Call ICL/Girobank I 5.4.2
Services Reception Centre
BPS (CMS & Girobank 5.4.3.2 & 5.4.3.3
PMS) Help Desks
Hardware ICL 5.4.3.5
Specialist Help
Desk
Software Specialist I ICL 5.4.3.4
Help Desk
Network Specialist I BT/ICL 5.4.3.6
Help Desk
Contract ICL 5.6
Management
Roll-out Verification ICL 74S
Supply ICL 746
Management
Site Preparation Camelot/ICL__I 7.4.8
System Build ICL TAS
Training Camelot/ICL 74.10
Delivery & Camelov/ICL I 7.4.11
Installation
6.7 SUMMARY
6.7.1 Pathway has approached the complex proving activities of the demonstrator and
operational trial phases by focusing proving from three viewpoints :
¢ Business Process completeness and support
* Service Characteristics comprehensiveness and completeness
* Technical Architecture strength and scalability
6.7.2 Our strategy is to prove to each user group that our solution meets their
requirements and will provide them with a low-risk quality service which
improves on the current working practice.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 39 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
Fin!
SECTION 6 - PILOT PROGRAMME
6.7.3
6.7.4
6.7.5
6.7.6
I SR6.1
We will manage the pilot programme as a PRINCE project to provide the
controls and visibility needed by both Pathway and BA/POCL. We will involve
BA/POCL user, customer and clients directly in the development process to
learn from them and ensure that we provide the services they require.
Our project plan covers the demonstrator and operational trial phases. We
consider the development process to be continuous during the entire pilot
programme.
We have been comprehensive in our proving approach to ensure that our
solution meets current requirements and is capable of expansion and
enhancement in the future.
We look forward to working with BA/POCL to complete this demanding
programme of work.
SPECIFIC RESPONSES
State any deviances from the requirements given in chapters 4, 5 and 7 relevant
to the services to be used during the pilot programme.
The deviances from the requirements given in Chapters 4, 5 and 7 which are
relevant to the services to be used during the pilot programme are :
Service : Deviation :
Payment Management Service Dependencies exist on the availability of
the CAPS interface definitions and the
interface itself during the programme
Card Management system It is not intended to provide full roll-out of
cards during this programme
Transaction Management system I It is not intended to provide inter-
operability with each POCL client, but to
prove the capability to connect to such
clients using generic software agents
Operational Support Service Only those facilities identified in the SSR
as being part of the initial solution will be
trialled
Counter Interface Only those facilities identified in the SSR
as being part of the initial solution will be
trialled
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 40 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
I SR6.2 State the level of project support that will be provided pre-contract-award, in
terms of the number and qualifications of the people assigned to the project, the
proportion of the time which will be devoted to the project, and where they will
be located.
Pathway is evolving its proposal development team structure into one that will
support activities during the period to contract-award. All Pathway directors are
in-post and committed to the proving activity. The management structures and
the teams resourced by Pathway itself are being assembled. Subcontract
resources have been committed and work packages are being assigned.
The overall management and control structure that we will use is based on the
use of PRINCE control structures. An executive organisation (Management
Board) under the Pathway Managing Director will control and monitor all
activities. A series of programmes or projects will be established under the
control of the Programme Director (Project Board Executive). The Technical
Director (Project Board Senior Technical representative) and Operations
Director (Project Board Senior User representative) will be present on all project
boards. The overall management structure is shown below :
Managing
Director
Business
Development Secretariat
Director
Quality & Risk____I Commercial & Financial
Management Director
Director _.
ooo ----- Programme. _---. ==. === I
Director if
Requirement Programme I
Control “~ Control I
Manager Manager
I I
Pilot Programme Roll-out Programme i
Manager Manager fal
Demonstrator Operational Live‘Trial Rollout I I
Team Trial Team Team Tem II
Technical Operations
Director Director
Technical I._Release & Service Development & ——} Service
Architects Integration Modelling Manager i Administration
Manager i
ee eT
Ae “I I i
evelopment POCL BA Help
Teams Service Service Desk
Manager Manager Manager
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 41 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
Within this structure, each Pathway director has specific responsibilities during
the proving programmes :
(a) Managing Director is the chairman of the Pilot Project Management Board.
He is responsible for ensuring that there is co-ordination between proving
activities, risk management and the development of the Pathway financial
proposal.
(b) Business Development Director is a member of the Pilot Project
Management Board. He is responsible for ensuring that we provide to BA
and POCL evidence of our ability to support their current and potential
future business requirements.
(c) Risk 8 Quality Director is a member of Pilot Project Assurance Team. He is
responsible for ensuring that all risks identified by BA/POCL and Pathway
are addressed, and removed or contained.
Financial & Commercial Director is a member of both the Pilot Project
Management Board and the Pilot Project Assurance Team. He is
responsible for ensuring that any commercial, contractual and cost
implications are identified and addressed as the programme proceeds.
(e) Programme Director is the Executive chairman of the Pilot Project Board.
He is responsible for co-ordinating all aspects of the pilot programme and
the roll-out programme that follows it.
(f) Technical Director is the Senior Technical representative on the Pilot Project
Board. He is responsible for the development and integrity of the Pathway
solution,
(g) Operational Director is the Senior User representative on the Pilot Project
Board. He is responsible for the development and operation of all the
supporting services.
d.
Under each director we are establishing teams of full-time Pathway staff and
subcontractors. The Pathway teams are based at the Pathway offices in Feltham.
Subcontractors are based at various locations in the United Kingdom, the Irish
Republic and the United States of America. All teams have been selected for
their qualifications in terms of the relevance of their experience and track record
in successfully undertaking similar tasks.
Each team has been allocated specific roles during the demonstrator and
operational trial phases. These are identified below together with the numbers
of Pathway staff involved. An indication has been given also of any
subcontractor involvement.
Responsible Director : Team Roles during Pilot : I Pathway Staff
Numbers :
Managing Director & Overall management 7
Pathway Directors
Business Development Reference visit support and I 5
formal interface to
BA/POCL during this
programme
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 42 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 6 -
Responsible Director: I Team Roles during Pilot : I Pathway Staff
Numbers :
Risk & Quality Risk register administration, I 3
risk management, quality
system management
Financial & Commercial
Development of financial
proposals, subcontractor
management, contract
negotiation
3 (+ Girobank, ICL
and De La Rue as
subcontractors and
Hambros as advisors)
Technical Development, modelling 3 (+ An Post/Escher
and agreement of solution subcontractors)
architecture, component
selection, subcontractor
control
Solution integration, 2(+ICL
releases packaging and subcontractors)
documentation
System design, (An Post/Escher, ICL,
development, test and A&L, Girobank
documentation subcontractors)
Programme Requirements modelling, 3
acceptance testing and
change control management
Programme planning 3
control across all
directorates
Pilot activity planning, 7 (+ internal
demonstrator phase subcontractors)
proving control, system
building, prototyping,
demonstrations, operational
trial control
Live trial and roll-out As shown in SR7.5
programme implementation
Operations Service administration As shown in SR5.1
Service definition &
modelling
3
POCL, BA and Help Desk
managers
As shown in SRS.14
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE
Page: 43 of 46
Date: 08/06/95
FUJ00098232
FUJ00098232
SECTION 6 - PILOT PROGRAMME
I SR6.3
I SR6.4
I SR6.5
State the service levels that can be attained during the operational trial.
The table below indicates the target service levels, relative to the steady state,
that can be attained during the operational trial.
Service Measure : Expected performance level(s) :
Counter system availability 98% of steady state level, improving
to 100% by end of trial
Counter system transaction time 100% of steady state level
Call to fix time for equipment faults I 100% of steady state level
Help desk queue times To reach 80% of steady state level by
end of trial
Transaction transfer to & from client I To reach >95% of current service
systems level by end of trial (Note : We would
wish to discuss the approach to
delivering these services during the
live trial including use of the POIT
Host Data Polling Centre)
Availability for BA interrogations To be discussed (depends upon the
service offered and CAPS status)
‘We assume that the number of live users and hence the volumes of transactions
that have to be processed will be such that a maximum of 2% of the anticipated
steady state volumes will be reached. We would wish also to discuss and agree
various characteristics of the operational trial, such as geographic scope, which
might have an impact on service levels.
State any differences between the operational trials and the roll-out in respect
of proposals for training, documentation, procedures and other support
services.
We intend to use the live trial to prove the training, documentation, procedures
and other support services prior to full roll-out. The versions of each used
during the trial will be of final draft status and we will amend them in the light
of the experience gained during the trial. At the end of the trial, the contractual
versions will be presented for acceptance with any changes from the trial
versions highlighted.
State how the Service Provider ideally sees the “Demonstrator” process taking
place and in what environment.
Pathway sees the demonstrator phase as an essential part of our proving
programme. We need to prove to BA/POCL and ourselves that our solution is
low risk, is built from proven components and will provide a user friendly and
intuitive interface to users, customer and clients.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 44 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
Sth
SECTION 6 - PILOT PROGRAMME
Proving our solution is a complex process. It requires us to prove that our
solution meets the needs of three different classes of user, BA/POCL
users/customers/clients, BA/POCL system managers and the Contracting
Authorities themselves. We will use different proving techniques for each
perspective :
Perspective: I Proved To: Techniques :
Business BA/POCL Reference visits to see similar applications
process Users, Demonstrations of options
customers, Prototyping of counter applications
clients Business process modelling
Service BA/POCL Reference visits to see similar services
characteristics I service Demonstrations of options
managers Service characteristics modelling
Technical Contracting Reference visits to see similar architectures
architecture Authorities End-to-end service modelling
End-to-end service simulation
Security and quality audits
Proving is about gaining buy-in to the system by being involved in its
development. We wish to involve BA/POCL users, customers, clients and
service managers as well as representatives of the Contracting Authorities in the
solution development process. We invite BA/POCL representatives to become
members of the Project Assurance Team (PAT) established to provide advice and
guidance during the pilot project. We will demonstrate hardware, software and
roll-out support alternatives to allow evaluation and selection of the preferred
option. We will establish a model office in which to validate the ergonomics of
counter hardware configurations and to measure counter transaction times.
We will demonstrate our capabilities in each of the service components by a
combination of reference, demonstrations, and model office usage. We will
prove our end-to-end service capability by reference and modelling during the
demonstrator phase in preparation for using simulation and live trial proving
during the operational trial phase.
We will base the demonstrator activities in our Feltham office but anticipate
considerable interaction with the BA/POCL evaluation team in London. It may
turn out in practice to be more effective to base the majority of demonstration
and prototyping activities in the BA/POCL-supplied accommodation in Victoria.
Review meetings can take place wherever most convenient to the BA/POCL
team but it is recommended that at least some of the reviews take place in
Feltham to allow the BA/POCL team to get to know the Pathway organisation
and see how it operates.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 45 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SECTION 6 - PILOT PROGRAMME
I SR6.6
I SR6.7
State the Service Provider’s view of how the post-award refinement of the
service and “live” testing will take place and how the results will be monitored.
The refinement of services can best take place by trialling them in live rather
than simulated environments. Pathway would like to start the live trial as soon
as possible after the start of the operational trial phase. This has a number of
benefits :
* Feedback from live use will cover migration issues as well as normal
operational use
* Live operation allows reconciliation processes to be exercised and the scale
and scope of the issues relating to reconciling in a mixed part-automated
part- non-automated environment to be evaluated and plans confirmed for
handling them during roll-out
¢ Training and documentation effectiveness can only be checked if the system
is used for a reasonable period of time to judge whether users feel confident
of using the system once the initial reactions to it have worn off
* Service Level Agreements need time to show trends so that improvements can
be monitored and the quality of service enhanced prior to roll-out
We consider the operational trial phase to be part of the overall pilot project.
The management and control structure we will use for this phase is that
described in SR6.2. During this phase, the operational element of our
organisation will build. We will gain direct feedback from our service managers
and would hope to receive similar information from their BA/POCL
counterparts. We will refine service components in the light of any feedback we
receive. In particular, we will monitor closely the acceptability of the counter
interface.
We will use the live trial period also to confirm our procedures for parallel
running and application cut-over. Subsequent phases of our roll-out will require
us to be able to handle live testing in parallel with normal operational usage.
This capability will be refined post contract-award.
We will monitor the results of both the end-to-end simulation activities and the
live trial by means of checkpoint meetings. We invite the BA/POCL members of
the PAT to attend. We would like also to have representation on any BA/POCL
monitoring committees for the live trial so that any issues raised, lessons learnt
and feedback gained can be dealt with as rapidly as possible. We wish to work
in partnership with BA/POCL to make a success of this phase and to proceed to
roll-out with confidence.
State the Service Provider's view of how the post-award refinement of the
service and “live” testing will take place and how the results will be monitored.
Please see our response to SR6.6.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 46 of 46
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
TABLE OF CONTENTS
ANNEX CONTENTS
1 ADDITIONAL FINANCIAL INFORMATION
2 PATHWAY QUALITY POLICY
3 CASH MANAGEMENT AND POST OFFICE RECONCILIATION
4 BASELINE PROPOSAL SUMMARY AND OPTIONS
5 PATHWAY SECURITY POLICY
6 CASE STUDIES
7 CURRICULUM VITAES AND ROLE DESCRIPTIONS
8 RESEARCH PROGRAMMES
9 TECHNOLOGY TRENDS
10 GLOSSARY OF TERMS
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
TABLE OF CONTENTS
ANNEX 1 ADDITIONAL FINANCIAL INFORMATION
4) ALLIANCE & LEICESTER ANNUAL ACCOUNTS
1994
1993
1992
2) BRITISH TELECOMM ANNUAL ACCOUNTS
1994
1993
1992
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 2. - PATHWAY QUALITY POLICY
TABLE OF CONTENTS
2. PATHWAY QUALITY POLICY.
2.1 GOALS. sseseessesenneenenseneennnnenen
2.2 TOTAL QUALITY MANAGEMENT.
2.2.1 LEADERSHIP...
2.2.2 POLICY AND STRATEGY
2.2.3 PEOPLE MANAGEMENT...
2.2.4 RESOURCE MANAGEMENT .
2.2.5 PROCESSES .
2.2.6 CUSTOMER SATIS!
2.2.7 PEOPLE SATISFACTION
2.2.8 IMPACT ON SOCIETY.
2.2.9 BUSINESS RESULTS
2.3 CONTINUOUS IMPROVE
2.4 QUALITY MANAGEMENT SYSTEM DOCUMENTATION
Ong;»twowwwnner ee
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 2 - PATHWAY QUALITY POLICY
2. PATHWAY QUALITY POLICY
21 GOALS
Pathway’s goal is to meet or exceed BA and POCL expectations throughout the
life of the contract.
This goal will be achieved by :
(a)
(b)
(c)
(d)
(e)
(f)
(g)
Adopting the Strategic Quality Model (SQM) within Pathway for Total
Quality Management, driven by customer needs.
Establishing and implementing a Quality Management System and relevant
processes, e.g. Subcontractor Performance Management, Service Level
Management, auditing and performance analysis and improvement.
Gaining ISO9001 or equivalent accreditation via Third Party assessment,
and ensuring all subcontractors meet this standard.
Developing a culture of continuous improvement in association with its
people, suppliers and processes.
Developing professional and interactive relationships with Pathway’s
suppliers to ensure customer satisfaction.
Building on the excellent pedigree in Quality Management brought by
Pathway’s subcontractors.
Cultivating a sense of pride and achievement in all the people associated
with Pathway.
This strategy for quality is depicted in Fig. 1 below:
Strategic Quality Model (SQM)
for
©
Total Quality Management
Quality Management System
I Continuous Improvement
I ISO 9001
Fig. 1 - Pathway Quality Management
Pathway Response to
COMMERCIAL IN-CONFIDENCE Page: 1 of 6
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 2 - PATHWAY QUALITY POLICY
2.2
2.2.1
TOTAL QUALITY MANAGEMENT
Pathway has adopted the Strategic Quality Model (SQM) for total quality
management. This model was developed by the European Foundation for
Quality Management, an organisation established in 1988 in recognition of the
potential for gaining competitive advantage through the application of total
quality.
The model has also been adopted by a number of national quality organisations
among them the British Quality Foundation of which ICL is a founding member
and whose Chairman and Chief Executive is Vice Chairman of the Foundation.
SQM provides the framework for continuous development by harnessing best
practice, encouraging teamwork, sharing knowledge and focusing on the
customer.
The model comprises nine management elements shown in Fig. 2 below :
People
Management
I
re I
Policy 8 ! Customer I
Seacey ° Sesfcron BSP"
Leadership
Processes
Business Results
7
I Impact on
Resources I lp Soceity
RESULTS ~~
Fig, 2 - Strategic Quality Model
LEADERSHIP
Overall ownership of the Quality Policy, and SQM process is vested in the
Managing Director of Pathway.
Each Director of Pathway is responsible for leading total quality management
within his functional area. The Director, Quality and Risk Management has
specific responsibility for establishing and maintaining the quality management
system.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 6
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
i awe
ANNEX 2 - PATHWAY QUALITY POLICY
2.2.3
2.2.4
Directors will be personally involved in defining and promoting Pathway’s
strategy and its provisions for quality to staff and subcontractors. They will
ensure that all feasible improvements are implemented and that people
responsible are duly recognised.
Pathway’s Directors and staff will play their full part in developing the spirit of
partnership with BA and POCL through regular meetings and reviews.
POLICY AND STRATEGY
The overall strategic and business plans are fully aligned and consistent with
total quality management.
Pathway will monitor the performance of all processes and subcontractors
closely and will strive to improve such performance through the revision of
plans, quality improvement programmes, and interactive cross-functional team
approaches.
PEOPLE MANAGEMENT
Pathway’s management style will be based on devolvement of responsibilities to
enable staff to achieve targets and objectives.
Pathway’s plans for the recruitment, training, appraisal and development of our
people will be derived directly from and aligned with business plans.
Through the process of continuous improvement described below all our people
will be involved jointly and severally in generating improvements.
Pathway will provide structured training in for example job skills, quality
development skills and customer service, to ensure that our people are fully
competent in what they do.
RESOURCE MANAGEMENT
Through the management information system, relevant performance data on all
aspects of Pathway’s service and operation, including the use of resources and
suppliers, will be readily available to appropriate staff within BA, POCL,
Pathway and suppliers.
PROCESSES
The structure of Pathway is based on its end-to-end processes each of which has
a nominated owner at Director level and, by the time of contract award, will
have been fully defined and characterised by specific performance indicators.
Responsibility for ensuring that ongoing process improvement is actively
pursued, is specifically assigned to the Director, Quality and Risk Management.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 6
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 2 - PATHWAY QUALITY POLICY
During the specification, design, build and implementation phase, performance
will be ensured by the use of the PRINCE project management methodology.
This is recommended by CCTA and defined in the NCC document entitled
‘Introduction to PRINCE’.
All operational and support processes will comply with ISO 9001, and we will
focus on :
(a) Internal processes that support the end-to-end operation of the Pathway
business
(b) Service level management, to ensure that Pathway meets or exceeds
expectations. The process will be agreed with BA and POCL
(c) Subcontractor performance management, which will include quality
assurance standards and procedures. Performance standards will be
specifically agreed with subcontractors at an early stage of system
development.
(d) Audit procedures will be developed in accordance with the requirements of
1SO9001. Internal audits of processes will take place regularly. Pathway
will expect external audits from customer representatives and relevant
accreditation bodies. In addition, we will undertake a programme of
surveys, visits and on-site audits of subcontractors. All audit trails, logs,
procedures, standards, non-compliances and reports will be available for
inspection at all times.
2.2.6 CUSTOMER SATISFACTION
The satisfaction of BA and POCL with Pathway’s services will be evaluated by :
(a) Ongoing management of the partnership between Pathway, and BA and
POCL, at every level.
(b) Specific monitoring and control of actual service delivery against the
contractual service level agreements.
(c) Applying robust measurement criteria in, for example, the following areas;
subcontractor performance, internal responsiveness.
(d) Conducting six-monthly reviews at dedicated meetings of the Management
Board.
These evaluations will be used to :
* Confirm customer satisfaction levels
¢ Agree targeted improvement plans
* Identify changing customer needs
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 6
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 2 - PATHWAY QUALITY POLICY
2.2.7 PEOPLE SATISFACTION
The satisfaction of our people, in all aspects of their work, will be evaluated by
an annual questionnaire and targets and programmes established for
improvement. These, and the results of the questionnaire will be communicated
through action-orientated team meetings. Regular comment and constructive
criticism will be encouraged at all times to maintain a focus on continuous
improvement.
2.2.8 IMPACT ON SOCIETY
Pathway will be actively seeking, through its partnership with BA and POCL, to
promote a shared and favourable impact on society in terms of conservation and
contribution to the community mindful that their clients comprise a large subset
of the public.
2.2.9 BUSINESS RESULTS
Pathway’s business performance is dependent upon achieving service level
agreement and therefore performance against these agreements will be reviewed
at relevant intervals.
Performance of Pathway’s internal processes will be similarly managed to ensure
that service level is totally without threat.
2.3 CONTINUOUS IMPROVEMENT
materials I
I Process I Customer
methods Feedback Feedback
; environment i
I I I
re —
ontinuous Focal
Improvement i i S I Los brea
pe ovemen I Business or Support b+ ot Product I
I J
I I
I J
Fig. 3 - Continuous Improvement
COMMERCIAL IN-CONFIDENCE Page: 5 of 6
Date: 08/06/95
Pathway Response to
OJEC Notice 94/S 165-58937/EN
FUJ00098232
FUJ00098232
SB as
ANNEX 2 - PATHWAY QUALITY POLICY
2.4
Pathway will implement continuous quality improvement within the overall
framework of the Strategic Quality Model.
Inputs to continuous quality improvement plans will be derived from :
(a) Feedback from BA, POCL and their clients
(b) Regular internal and external audits of business and support processes
(c) Feedback from suppliers and Pathway staff
This will be facilitated by regular meetings led by process owners, with the
objective of agreeing action plans, monitoring and controlling progress.
QUALITY MANAGEMENT SYSTEM DOCUMENTATION
The Quality Management System will be supported by a comprehensive set of
documentation, describing appropriate processes and procedures, in accordance
with the requirements of IS09001. This will consist of :
(a) Quality Manual, which will state Pathway’s policy, define end-to-end
processes and provide a documented set of managerial instructions.
(b) Control procedures, which will define detailed methods and controls used
to assure Quality, for example, design procedures and_ standards,
subcontractor standards, change procedures, audit procedures.
(c) Work instructions which will define procedures for specific tasks, for
example, test specifications, upkeep of documentation, meeting minutes.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 6
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 3 - CASH MANAGEMENT AND POST OFFICE RECONCILIATION
TABLE OF CONTENTS
3. CASH MANAGEMENT AND POST OFFICE RECONCILIATION
3.1 CASH MANAGEMENT ....csccsssseseesssssenenenenennennnersees
3.1.4. POST OFFICE/CASH CENTRE INFORMATION LINK
3.1.2 FLOOR/CEILING LEVELS AT POST OFFICES:
3.1.3 CASH DISTRIBUTION...
3.1.4 BA INFORMATION LINK
3.1.5 OTHER CLIENT INFORMATION LINKS
3.1.6 REPORTING AND MIS...
3.2 POST OFFICE RECONCILIA’
3.2.41 AUTOMATED POST OFFICE..
3.2.2 NON-AUTOMATED POST OFFICE.
3.2.3 POCL CENTRAL PROCESSING ....
3.2.4 CASH ACCOUNT SUMMARIES FROM AUTOMATED POST OFFICES .. .
3.2.5 CASH ACCOUNT SUMMARIES FROM NON-AUTOMATED POST OFFICES DURING
3.2.6 DOCUMENT PROCESSING
3.2.7 REPORTING AND MIS...
3.2.8 DATA DISTRIBUTION TO CLIENT:
3.2.9 ERROR NOTICE ACCOUNTABILITY
3.3 CLIENT/POCL RECONCILIATION
3.3.1 BENEFITS AGENCY ...
3.3.2 OTHER POCL/CLIENT
ORERWNNNNNERBE
OOO ooo ool
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 3 - CASH MANAGEMENT AND POST OFFICE RECONCILIATION
3. CASH MANAGEMENT AND POST OFFICE
RECONCILIATION
3.1 CASH MANAGEMENT
3.11 POST OFFICE/CASH CENTRE INFORMATION LINK
3.1.1.1 As an optional Value Added Service, Pathway will provide an automated system
for the complete management of the large volumes of cash circulating
throughout the Post Office network, with the ability to control distribution of
cash and provide forecasting and funding information. Pathway recognises the
requirement for the system to be secure with restricted access because of the
high value of cash involved. Benefits of fully automated Cash Management
include :
¢ Breakdown of notes by denomination
* Maximum investment opportunity and return for overnight cash holdings
* Accurate funding and forecasting information
¢ Reduced risk of fraud at counters and cash centres
* Information on end-of-day balances which will enable the cash centre to alert
security carriers to collect and distribute cash
* Accurate calculation of security carrier fees
* Reduced need for manual cash orders
¢ Audit trails of cash distribution
¢ Improved control of coin stocks
3.1.1.2 Pathway will provide a system to link all post offices electronically with their
affiliated cash centres in order to introduce a total cash management system. A
two-way link will allow communication between an individual post office and
its cash centre providing the facility to monitor cash availability throughout the
day.
3.1.2 FLOOR/CEILING LEVELS AT POST OFFICES
All post offices will be given pre-determined floor and ceiling levels for cash
held. In addition to random daily cash monitoring by the cash centre, any post
office with a cash position falling outside the floor and ceiling levels will
automatically alert the cash centre that a delivery or collection is required.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 6
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
on
ANNEX 3 - CASH MANAGEMENT AND POST OFFICE RECONCILIATION
3.1.3 CASH DISTRIBUTION
With a given post office’s cash position being available at any time throughout
the day, the cash centre is able to collect or supply cash to offices when
required. End-of-day cash availability ensures that collection can be made
quickly and visits to post offices are only necessary if the end-of-day cash
position has fallen outside the floor or ceiling level, or a Postmaster has declared
a surplus for collection. This cash distribution procedure will improve security
for POCL and their security carriers by minimising the number of trips
necessary. It will also bring associated cost savings and improved investment
opportunities.
3.1.4 BA INFORMATION LINK
If required to facilitate the pre-funding of certain smaller post offices for high-
value social fund loans, an electronic link to the system may be provided to BA
to allow notification of such details to POCL. This information link would be
password-protected with restricted access granted to BA which would not allow
interrogation of the overall cash position within POCL.
3.1.5 OTHER CLIENT INFORMATION LINKS
Following full automation, it may prove advantageous for other major POCL
clients to have restricted access to the cash management system to allow
notification of high-value deposits or receipts that may significantly affect the
POCL cash availability. This service will be provided subject to negotiation with
POCL.
3.1.6 REPORTING AND MIS
In addition to the general reports available to each post office covering their
day-to-day business, a comprehensive set of reports will be available to POCL
centrally covering the following :
* Daily national cash availability
* Cash available for each post office at the end of the working day
* Cash collections and deliveries
* Floor and ceiling level amendments
* Pre-funding requirements
* Security carrier fee calculations
3.2 POST OFFICE RECONCILIATION
During roll-out the Cash Account for all post offices (automated and non-
automated) will continue to be produced each Wednesday.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 6
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 3 - CASH MANAGEMENT AND POST OFFICE RECONCILIATION
3.2.41
3.2.1.1
3.2.1.2
3.2.1.3
3.2.1.4
3.2.1.5
AUTOMATED POST OFFICE
As part of the Operational Support Services, Cash Account production,
Postmasters remuneration and Cash Management facilities are required from
day one of the procurement for all automated offices. During roll-out it is
envisaged that the production of the Cash Account will remain weekly. The
Pathway system is flexible and will allow for the production of the Cash
Account on a daily basis if required. Post offices that are automated will capture
all transactions including those that are not automated (see Annex 3.2.1.3
below). Transaction data will be polled to provide single settlement figures for
POCL clients and the Postmasters’ remuneration information for POCL.
DAILY BALANCE
The facility to provide a daily balance at each counter position will be available
from day one for automated offices. Cash and value stock movements between
counter positions will be identified and recorded for security purposes. Balances
from each counter position will be summarised to provide the overall post office
daily balance.
START-OF-DAY PROCEDURE
The Postmaster must ‘open’ the system at the start of each day. This will prompt
the breakdown (by type, quantity and value) of the cash and stock on hand to be
displayed. The system will provide the facility for the Postmaster to add or
transfer stock (including cash, cheques and other items of financial value) to and
from the office and provide him with an up-to-date figure of cash and stock
available to complete the day’s transactions.
INPUT OF NON-AUTOMATED TRANSACTIONS
Transactions that are not automated will be input at summary level at each
counter position before the end-of-day procedures are activated.
END-OF-DAY PROCEDURE
Following input of the final transactions for the day (including non-automated
transactions) each counter clerk must initiate the end-of-day procedure. The
Postmaster will be able to complete stock transfers and identify the next day’s
cash requirements enabling completion of business within the same day.
DAILY CLIENT SUMMARY PRODUCTION
Summaries of automated transactions will be produced during the end-of-day
procedure for every client. Information produced will be at transaction level and
will include volume, value, type and fees where applicable.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 6
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
%, id
ANNEX 3 - CASH MANAGEMENT AND POST OFFICE RECONCILIATION
3.2.1.6
3.2.1.7
3.2.1.7.1
3.2.1.7.2
3.2.2
3.2.3
3.2.3.1
3.2.3.2
DAILY REPORTING & MIS
Daily reporting will be available after the completion of the end-of-day balance
at the counter. The information will include :
(a) Sales Analysis - an analysis of product sales by volume, value and time.
(b) Contribution Analysis - a report of business performance for individual post
offices.
(c) Quality of Service - an analysis of the transaction time and customer count
for individual post offices from transaction details.
CASH ACCOUNT PRODUCTION
During the roll-out, which is expected to take between 24 and 36 months, it is
envisaged that the production of the Cash Account summary will continue on a
weekly basis to enable the full integration of the automated information and the
manual Cash Account, raising one settlement figure for each client.
When the end-of-day procedure on the last day of the Cash Account week has
been completed, weekly client summaries and MIS reports will be output. The
Postmaster will be prompted to initiate production of the Cash Account, using a
series of screen commands. Data from the full office balance will be transmitted
to Pathway.
Following roll-out, the Pathway solution will provide POCL with the facility to
build in pre-determined dates for the production of the Cash Account.
NON-AUTOMATED POST OFFICE
During roll-out, non-automated offices will transact business as usual and
produce a full reconciliation and Cash Account summary. Post offices will
continue to complete cash and stock reconciliations, the Cash Account summary
and any other paperwork (for example, client summaries and other client
documentation). ECCO+ or Capture systems within these post offices will still
be fully functional.
POCL CENTRAL PROCESSING
POCL receive weekly Cash Account documents from all post offices and CRUs
at either Chesterfield or Edinburgh processing centres. Cash Account documents
from automated and non-automated post offices will be merged within the
POCL reconciliation system to produce a national balance. Transaction data is
then forwarded to clients electronically or in paper format as with current
POCL client agreements.
As a Value Added Service, Pathway would welcome the opportunity to bid for
all the processing of the Cash Account summaries during the roll-out period.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 6
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
3.2.4
3.2.5
3.2.6
3.2.7
3.2.7.1
3.2.8
3.2.9
CASH ACCOUNT SUMMARIES FROM AUTOMATED POST OFFICES
Following close of business, each automated office will complete the end-of-day
procedures necessary to generate the daily post office reconciliation, All post
offices will be ‘polled’ to ensure 100% availability of data to POCL.
CASH ACCOUNT SUMMARIES FROM NON-AUTOMATED POST OFFICES
DURING ROLL-OUT
Cash Account summaries from non-automated post offices are remitted to
POCL for input into the reconciliation system. Current arrangements for
despatching the Cash Account to the central processing units will not change
during roll-out.
DOCUMENT PROCESSING
Current arrangements for POCL client paper processing will apply until such
time that clients specify their full requirements of the automated system. The
Pathway solution has the functionality to provide transaction data to clients
electronically after full data capture at the counter. It is envisaged that existing
arrangements for the processing of financial items (such as transfers, gift
vouchers, saving stamps, other banks’ cheques and cheques made payable to
“Post Office Counters Ltd’) will not change.
REPORTING AND MIS
As part of the Operational Support Services, Pathway will provide the reporting
and MIS function for automated offices from day one of the procurement.
Reports and MIS will be generated centrally by Pathway following
implementation of end-of-day procedures. The frequency of reporting will be
determined by POCL, however the nature of the system allows all reports
(including the Cash Account) to be produced on a daily basis if required.
Reports will be available as described in sub-section 3.1.6 above.
DATA DISTRIBUTION TO CLIENTS
If required fully reconciled data will be delivered electronically to POCL client
systems within agreed timescales. Clients may complete their own reconciliation
to balance against the incoming figures from POCL.
ERROR NOTICE ACCOUNTABILITY
Where errors are identified following completion of the Cash Account summary,
error notices will be raised against the post office concerned, as is currently the
case. Error notices will be brought to account, as with current procedures, by
adjusting the cash-on-hand situation and including them as transactions to the
appropriate customer.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 6
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 3 - CASH MANAGEMENT AND POST OFFICE RECONCILIATION
3.3
3.3.1
3.3.1.1
3.3.1.1.1
3.3.1.1.2
3.3.1.2
3.3.2
CLIENT/POCL RECONCILIATION
BENEFITS AGENCY
AUTOMATED POST OFFICES
To achieve a full reconciliation between BA and POCL, all transactions
(automated and non-automated) will be input at the counter for inclusion within
the Cash Account.
(a) Capture of automated BA transactions authorised by CMS and PMS will be
complete and provide a full issue/encashment reconciliation. Reporting and
MIS will be available for BA and POCL from day one via OSS and the
Benefit Payment Service (BPS).
(b) Non-automated BA transactions will be input at the counter before the end-
of-day procedures are activated. Girocheques will be sent to Girobank,
where a full reconciliation will be completed and settlement figure raised.
Foils will be despatched to Benefit Agency as per current arrangements.
Following roll-out and full automation, all BA transactions will be captured at
the counter and a full BA/POCL and issue/encashment reconciliation will be
completed as required.
NON-AUTOMATED POST OFFICES
During roll-out there will be no change to the current procedure for BA
issue/encashment reconciliation. Girocheques will be reconciled, settlement
raised via Girobank and foils despatched to Benefit Agency.
OTHER POCL/CLIENT RECONCILIATION
During roll-out Cash Account data will be delivered electronically or in paper
format on a weekly basis to POCL client systems within agreed time scales.
Following roll-out, the Pathway solution will have the flexibility to meet POCL
and client requirements for the provision of transaction and settlement
information.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 6
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 4 - BASELINE PROPOSAL SUMMARY AD
TABLE OF CONTENTS
4 BASELINE PROPOSAL SUMMARY AND OPTIONS
4.1 INTRODUCTION
4.2 SERVICES........
4.2.1 OPERATIONAL SERVICE
4.2.2 SUPPORT SERVICES...
4.2.3 CONTRACT MANAGEMENT SERVIC!
4.2.4 CONTRACT TRANSFER SERVICE...
4.3 HARDWARE, SOFTWARE AND APPLICATION:
4.4 REDUCED COST STRATEGIC INFRASTRUCTURE.
4.4.1 F85 OPTIONS... ees
4.4.2 OPTION 1. F8S SLAVE TERMINAL To A PC! iN A LARGE OFFICE
4.4.3 OPTION 2. STAND ALONE F85 TERMINAL EMULATING A PC.
4.4.4 DE LA RUE - F85 CASE STUDY.
4.5 PRODUCT DESCRIPTIONS
4.5.1 COUNTER PC.........
4.5.2 COUNTER MONITO
4.5.3 KEYBOARD .
4.5.4 COUNTER PRINTE!
4.5.5 READER DEVICES.
4.5.6 BACK-OFFICE PRINTER..
4.5.7 ISDN CARD.
4.5.8 ADDITIONAL
4.5.9 SERVERS ON THE BACKBONE NETWORK.
COMDWMNUTTWWNHYNEBRBE
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
4 BASELINE PROPOSAL SUMMARY AND OPTIONS
4.1 INTRODUCTION
This Annex describes the baseline proposal in terms of operational and support
services and provides a summary of the hardware and software that Pathway
envisage using for these services. An alternative approach to the counter
infrastructure for certain post office counters is described in Sub-section 4.4 of
this Annex. Sub-section 4.5 of this Annex provides a more detailed technical
description of the hardware that Pathway envisages using for the baseline
proposal. A number of alternative counter peripherals are available and some
options are also included.
4.2 SERVICES
4.2.1 OPERATIONAL SERVICES
4.2.1.1 CARD PRODUCTION AND DISTRIBUTION
The manufacture, personalisation and distribution of cards to post offices and
BA offices.
4.2.1.2 CARD MANAGEMENT SERVICE
A centrally managed service to control the issue of new and replacement plastic
cards (magnetic stripe and smart). The service maintains records of the status of
all cards and supports on-line status enquiries.
4.2.1.3 PAYMENT MANAGEMENT SERVICE
A secure, robust and fully auditable service which manages the authorised
benefit payments and their subsequent encashment or expiry.
4.2.1.4 TRANSACTION MANAGEMENT SERVICE
A fault-tolerant messaging system based on Riposte. It manages all the counter
interface transactions, invokes value added processes and interfaces with POCL
client systems in a secure manner.
4.2.1.5 COUNTER INTERFACE SERVICE
The counter system which enables counter staff to use the POCL infrastructure
for EPOS, benefit payments, Bill Payments, etc.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
4.2.2
4.2.2.1
4.2.2.2
4.2.2.3
4.2.3
OPERATIONAL SUPPORT SERVICE
A number of applications (some local to post offices and some run centrally)
that provide reports to help manage the POCL business. These include Outlet
Remuneration and Reconciliation, Reporting and MIS. Future applications
include stock management, cash management, purchase order management,
financial accounting, staffing, administrative support.
SUPPORT SERVICES
HELP DESK CALL RECEPTION AND CALL TRACKING
A sophisticated Call Reception Centre with a call handling system and incident
database, which records calls and progresses the resolution of problems. The
database assists with identifying the reported problem and the call details are
passed on to the appropriate help desk.
SPECIALIST HELP DESKS
There are a number of specialist help desks, which provide a comprehensive set
of support services and are normally accessed via the Pathway Call Reception
Centre. Each of the help desks is interrelated and is staffed by experts in its
own field :
* CMS
* PMS
* Technical help desks - Software, Hardware and Networks
* Roll-out help desk
The technical help desks can use the appropriate support services, including
equipment repair teams, software specialists and BT engineers.
UNDERLYING SUPPORT SERVICES
A comprehensive range of support procedures and activities which include
change control, configuration management (including network changes),
upgrades, equipment relocation, reference data management, training and
documentation, MIS and SLA monitoring.
CONTRACT MANAGEMENT SERVICE
This handles contract variations, audit controls, security controls, quality
management (including Codes of Practice), monitoring customer complaints,
and business development.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
4.2.4 CONTRACT TRANSFER SERVICE
The activities and procedures needed to facilitate the seamless transfer of any
service from Pathway to a new Service Provider, at the end of the initial contract
term.
4.3 HARDWARE, SOFTWARE AND APPLICATIONS
The following table summarises the baseline proposal, and sets out the options
available.
The baseline proposal Examples Options
(a) Per Counter
* 486 DX PC Fujitsu ICL ErgoPro * Touch Screen
€440/66
* 540Mb disk “ ¢ Thermal Printer
+ 16Mb RAM “ * Multi-function
printer
* Colour Monitor ICL 9” SVGA * Weigh Scales
model C90C * Customer-Facing
¢ Tally-roll Impact Printer I Ithaca 5OPLUS Display
* Compact Keyboard Alphameric
* Magnetic Stripe Reader I } ARL (combined
(MSR) } OCR/MICR/MSR +
* OCR Reader } Bar Code wand)
¢ Smart Card Reader Current APPU or
combine in above
reader
* Windows - NT
« Riposte
(b) Per Office
* Ink Jet/Matrix Printer for I Fujitsu DL3700 ¢ Alarm system link-
back-office up
¢ ISDN Card Eicon DIVA * Separate 486 DX
* CBT PC for back-office
with
some/all counter
peripherals
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
The baseline proposal Examples Options
(c) Backbone Network servers
{over 4 physical sites)
* Correspondence Servers I Compaq ProLiant
(multiple Intel dual/quad I model 4500R
Pentiums)
+ ISDN front-end Eicon 2M ISDN card
processors, Agents &
System Management
servers (multiple Intel
dual Pentiums with
Windows - NT or UNIX)
¢ Riposte
* Windows - NT
(d) PMS (2 sites)
* Tandem Himalaya
configurations, highly
resilient
(e) CMS (2 sites)
* Tandem Himalaya
configurations, highly
resilient.
¢ ACI’s card management
application
The baseline proposal Options
(f) Applications
Bill Payment
¢ APT migration
+ Additional Utilities and other
companies
Benefit Payment
° ESNS Options in roll-out stages
* Enhanced ESNS ce ee.
* Full payment (PMS) “ «ee
EPOS
* ECCO+ replacement
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
is
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
The baseline proposal Options
OSS Local
* ECCO+ replacement Integration of RIVA back-office
cash accounting and stock control
* Postmasters Remuneration
* POCL Reconciliation (Cash
Account)
* MIS & Reporting
OSS Central
¢ MIS & Reporting * Reconciliation of non-
* BA/POCL Reconciliation automated BA transactions
(foils) during transition
* POCL Cash Centre
Management & Reconciliation
* Client/POCL Reconciliation
¢ Resource Planning
* Product Line Profitability
(g) Other Applications
* Mails
* Licences
* Savings Accounts
* Foreign Exchange
¢ Insurance
* Travel Tickets
4.4 REDUCED COST STRATEGIC INFRASTRUCTURE
44.4 F85 OPTIONS
Pathway recognises that transaction volumes across post office counters peak on
Mondays and Thursdays due to particular benefits becoming due. This is
particularly acute in the larger post offices since they handle a large proportion
of the overall transaction volume. As a consequence Pathway believes that a
number of counter positions in these offices may not be utilised fully at other
periods.
It is also estimated that 5,000 of the smallest rural sub-post offices together
perform approximately 1% of the total business transactions.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
In order that the costs of the POCL Strategic Infrastructure can be optimised for
these counter positions Pathway can provide an alternative to the full PC-based
infrastructure. This is based on the De La Rue Fortronic F85 payment terminal
which provides the minimum functionality offered by the full PC solution,
including receipt printer, OCR reader, magnetic stripe and smart card reader.
The F85 is a small-footprint, integrated payment terminal, currently used at over
120,000 retail points of sale within the UK and Europe to process credit and
debit transactions.
The F85 is used also as a bill payment terminal by a number of the electricity
companies, see the Case Study in Sub-section 4.4.4 of this Annex.
The F85 is a compact, integrated terminal (220mm by 260mm) with keyboard
(numeric plus function keys), display (2 rows of 20 characters), journal printer,
magnetic card reader, and smart card reader. It also incorporates the
communications required (including 3 RS232 ports to facilitate the attachment
of other peripherals such as bar code/OCR readers) to meet the post office and
Benefit Agency requirements.
Two options exist (see Fig. 1) for using the F85 instead of a PC at the counter
position :
(i) The use of the F85 as a slave terminal from a PC in the larger post offices.
In this case the PC will run two copies of the Riposte software and the
counter application software with a simple device driver interfacing to the
F85 from the PC. Logically this makes a single PC look like two counter
positions to the correspondence server.
(ii) The use of the F85 as a PC alternative in the small post offices with only
one counter position (or where the volume of transactions could not justify
a PC). In this case the F85 will appear as a PC equivalent and BA
transactions would be transmitted and stored within the F85. A front-end
terminal concentrator will be employed at the correspondence server to
handle the connection to F85s at remote offices.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
4.4.2
Backbone Network
Correspondence Servers
fo +h Network >
Branch Networ' )
\ /
fo me
\
\
Counter
I Infrastructure
Post Offices Counter Configurations
PC based with option of F85 option for low
F85 for overflow counters usage counters
Fig. 1 - F85 options
Each of these two options is considered in more detail below.
OPTION 1. F85 SLAVE TERMINAL TO A PC IN A LARGE OFFICE
In this option the F85 would act as a set of remote but highly integrated
peripheral devices to the PC and provide access to Benefit Agency transaction
data stored on the PC. This allows two counter positions to access the data
processing capability of the PC and the full capability of the Pathway solution.
The PC contains all transaction data related to the F85 and the generic
architecture of the Pathway solution is maintained. From a system point of view
a single PC appears as two counter positions,
This is proposed as an option since it is not an off-the-shelf solution and would
require development of the PC software to support the slave devices and
development of the F85 terminal application to interface with the PC.
This proposal provides a small-footprint integrated terminal for a number of
counter positions that may only be used at peak periods in the larger offices
(Monday and Thursday mornings).
While the user interface of the F85 is different to a PC, the logical flow of a
transaction on an F85 and a PC would be the same and would involve the
following actions :
1. Swipe customer card to identify customer
2. Access PC database to retrieve benefits due (or access across the network in
the case of foreign payments)
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 7 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
3. Display amount and confirm amount with customer
4, Print receipt and request customer signature
5. Verify signature and make payment to customer
Since all transactions performed on the F85 are recorded on the PC, the full
end-of-day reconciliation facilities as performed on the PC are also available to
the F85 (including automation of the Postmaster’s Daily Record and ECCO+
facilities).
4.4.3 OPTION 2. STAND ALONE F85 TERMINAL EMULATING A PC.
In this option the F85 would receive BA payments from the correspondence
server in the same way as a PC running the Riposte software. The F85 will
store the BA payment details in the terminal’s secure battery-backed CMOS
memory. Transactions would be performed on the F85 in the same way as on a
PC as described above in Option 1, and the completed transaction details
forwarded to the correspondence server in a similar way to the PC solution,
with F85-specific processing on the correspondence server.
The F85 has the capability of storing approximately 1000 BA transactions and
1000 Bill Payment transactions along with the full application required for the
BA, Bill Payments and a simple ECCO+ end-of-day application in the 1
Megabyte of memory available.
4AA DE LA RUE - F85 CASE STUDY
4.4.4.1 MAIN FEATURES OF CONTRACT
* Customer Service Driven
* Accurate Collection of Sales Data
¢ Futures Options
4.4.4.2 CONTRACT TERMS
In 1985, East Midland Electricity introduced card-operated token meters for
domestic customers. Initially this service was provided for premises where there
were security problems, i.e. break-ins. The meters were a success, however the
number of card meters grew and the demand for cards caused large queues
which caused adverse reactions from customers and staff.
East Midland Electricity then invested in automatic token-dispensing machines
provided by De La Rue. The business objectives of the new system are therefore
to improve customer service and efficiency with inherent reduced costs.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 8 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
4.4.4.3
444.4
4.5
DESCRIPTION OF TASK
For the data capture equipment, the company invited nine electronic receipting
equipment suppliers to tender. Originally, sixteen terminals were used on trial.
After three months, everybody agreed that the system worked well.
The most important requirement was to capture the sales data and have it passed
quickly and accurately back into the records system. East Midlands also needed
control of the stocks of tokens and the costs held by the retailer to protect
themselves against any possible fraud or loss.
The customer’s meter continues to be read every three months and charges for
electricity calculated from the reading. Every time the customer purchases
tokens, he presents a plastic card (which has been encoded in-house with the
customer’s account number and his meter type) to identify him and authorise
the transactions.
Each transaction is entered onto his account record every three months and an
invoice is prepared which reconciles meter readings with token pre-payments so
that, hopefully, the invoice will be zero.
BUSINESS BENEFITS
¢ Improved Customer Service
¢ Improved Productivity
* Cost Effectiveness
A measure of the success of the installation of the Fortronic terminals may be
gauged from the fact that some £400,000’s worth of transactions were handled
by them in the first three months of operation.
PRODUCT DESCRIPTIONS
Brief product descriptions for selected hardware components for the counter
interface and TMS follow. These are given for illustrative purposes only at this
stage. Final selection of the counter infrastructure will take place following the
usability and functionality assessments described in Section 6.2, Proving
Approach,
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 9 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
4.5.1 COUNTER PC
(a) Fujitsu ICL ErgoPro e440/66
The ErgoPro 440/66 is based on the powerful Intel P24D-66 processor
supporting ISA and offering integrated fast local bus graphics.
The principal facilities are :
Integrated fast local bus graphics supporting overscan
IDE interface
PowerMaster 2.2 for efficient power management
Maximum fixed disk capacity of 1GB
Optimised temperature control
Quiet in operation
Technical specification
Processor
Bus Architecture ISA
Processor Write-Back enhanced Intel DX2-66
Clock Frequency 66 MHz
Memory 4 to 64MB RAM
Cache 0 or 256Kb second level cache
OverDrive processor support Intel DX40DPR100
Storage Device Options
One front-accessible 5.25” bay. Options include Tape streamer or CD-
ROM.
Two internal 3.5” bays for 540MB hard disks.
One 3.5” 1.44MB diskette drive.
Expansion Slots
Four 16-bit ISA slots
Operating Conditions
Power supply unit 120W (switchable, with monitor outlet)
Ambient temperature +10°C to +35°C
Relative humidity 20 to 80 %, non-condensing
Mains input 115/230 V AC +15/-22 %, 50/60 Hz + 5%
Noise Level ss 32 dBA at + 25°C when idling
(according to ISO 7779, < 40dBA at + 25°C when in operation
ISO 9295 operation)
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 10 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
Dimensions and Weight
Height 122mm Depth 432mm
Width 368mm Weight 8 to 12 Kg
4.5.2 COUNTER MONITOR
(a) ICL 9” SVGA Colour Monitor
Resolution 800 x 600
Scanning Frequency Vertical S6Hz, Horizontal 35.2 Khz
Dot Pitch 0.28mm
Input Voltage 100-240, 50/60 Hz
AC Power Consumption 60W (max)
Weight 6Kgs
Dimensions (mm) 262 (width) x 315 (height) x 260 (depth)
Temperature 5 - 40°C
Operation 5 - 80% relative humidity
(b) Options
Options that could be considered for the counter monitor are :
Touch screen monitors including 10” SVGA colour TruePoint monitor or
9.5" colour LCD touch monitor from MicroTouch.
4.5.3 KEYBOARD
(a) Mini Desk PC/AT Keyboard
A compact 86-key keyboard which is fully PC/AT compatible.
Dimensions (mm) 290(width)x x140(depth) x 22(height)
(b) Options
A wide variety of keyboard designs are available including separable
numeric keypads, combined card readers and a re-configurable and
programmable key matrix.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 11 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
4.5.4 COUNTER PRINTER
(a) Ithaca 50plus counter printer
The Ithaca 5Oplus series printer is a 4-lines-per-second impact printer which
can use one-, two- or three-part paper and can combine receipt, journal and
validation printing functions.
Media
Receipt / Journal paper Standard size (82.5 mm x 89.0 mm)
Single/Double/Triple ply paper 74.6m /38.1m/25.9m
Dimensions (mm) 171.5 (width)x292.1(length)x177.8(height)
Weight 6.81 Kg
Temperature range 5°C to 50°C
Humidity range 20 to 90% Relative Humidity
Reliability 20 million print lines
Mean Cycle between Failure 25,000 hours
Mean time to Repair 15 minutes
Print Head life 200 million characters
Ribbon life 6 million characters
Cutter life 1 million cuts
(b) Options
Options that could be considered for the counter printer are :
(i) AXIOHM APOS thermal printer
This range of thermal printers provide simple, fast and silent operation
for a range of point of sale applications. The printer is easy to use with
paper loading taking less than two seconds.
Printing method Fixed thermal head
Paper Standard thermal paper
or industrial label stock
Paper roll length 82m
Print speed 80 mm/sec
Printhead life 100 km of paper
Cutter life 1 million cuts
Dimensions (mm) 170(width) x 115 (height) x 205(depth)
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 12 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
(ii) Siemens Nixdorf ND69 POS printer
The ND69 pin printer is a high-performance POS system printer of
receipts, journals and A4 documents. It provides an option at the
counter for printing a wide range of document types and sizes that may
be required in EPOS applications.
Print bi-directional
Receipt/Journal paper up to 76mm wide
up to 90m long (single ply)
Document paper single or multi-ply paper
Print Speed 4 lines per second - receipt printing
1.8 lines per second - A4 roll / forms
Ribbon life violet (9M characters)
black (6M characters)
Printhead service life 100 million characters
Cutter service life 500,000 cuts
Dimensions (mm) 280(width) x 367(depth) x 222(height)
Weight 13.5kg
Operating temperature 5°C to 40°C
Humidity 5% to 85%
Power 80 Watts
4.5.5 READER DEVICES
(a) Multi-function reader module (OCR, Magnetic Stripe, Bar Code, MICR)
Utilising existing, proven and reliable technology Pathway, in conjunction
with Advanced Recognition Limited, can provide a basic Multi Function
Reader Module which meets the requirements for OCR, Mag. Stripe, Bar
Code and MICR data capture requirements in the minimum footprint size.
The basic Multi Function Reader Module, which is based on the
DOCUmatic 7000 Motorised Reader, provides the following data capture
functions :
(i) Optical Character Recognition (OCR)
The basic Multi Function Reader Module has two OCR readers.
The first OCR reader is an optical reading head mounted within a
motorised document transport. This enables Utility bills and
potentially girocheques to be easily read with the minimum of user
activity.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 13 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
The read head is designed to read E13B/OCR-B Mixed Font Code
lines, but may be electronically switched to also read OCR-A or
OCR-B.
The optical read head is a fixed-position device and is designed to
scan any code line printed in accordance with the UK Inter Bank
standard for code line height, ie. characters printed from 3/16" -
5/16" from the bottom reference edge of the document.
The second OCR reader is a Hand Held ‘OCR Wand’. This is a
‘near contact’ device capable of reading single or multiple data fields
of OCR-A or OCR-B characters and 1D Bar Codes. The hand held
wand reader is a bi-directional reader and has a reading speed of
from 30-130 characters per second.
(ii) OCR Security
The hand-held ‘OCR Wand’ reader is able to read OCR machine
printed characters which have been totally obscured, making them
completely invisible to the human eye. This security process is
achieved by using a different ink formula for printing the data to that
used to obscure the data. The data to be read would appear to the
viewer as a black block.
When the black block is scanned by the ‘OCR Wand’ the data is
captured in the usual manner. Any attempt to photocopy the data
fields will only produce a further black block.
(iii) I Bar Code Scanning - One Dimensional
The hand-held ‘OCR Wand’ mentioned above can also be provided
with the facility to read most one-dimensional bar code symbologies.
Due to the technology used in the hand-held wand, this system is
unable to read two-dimensional bar codes.
(iv) I Magnetic Ink Character Recognition (MICR)
The basic Multi Function Reader Module has one Magnetic Ink
(MICR) read head which is mounted within the motorised
document transport. The magnetic ink read head is designed to read
E13B (MICR) characters typically found on bank cheques and
credits.
The magnetic ink read head is a fixed position device and is designed
to scan any code line printed in accordance with the UK Inter Bank
standards for code line height, ie. characters printed from 3/16" -
5/16" from the bottom reference edge of the document.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 14 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
(v) Magnetic Stripe Reading
The basic Multi Function Reader Module also incorporates a manual
bi-directional Magnetic Card ‘swipe’ reader capable of reading
Tracks 1/2 & 3. The magnetic card reader head is fixed position
device and is designed to read all magnetic cards encoded to
established banking standards.
(vi) Host Interface
The basic Multi Function Reader Module provides an RS 232C
interface for connection to counter PC. Other interfaces are
available subject to the user requirements.
(vii) Software Programming
The basic Multi Function Reader Module has a variety of custom
user-programming options to allow the validation of captured data
prior to transmission. These would include Field Length Validation.
Check Digit Verification, Field Content Validation, Joint Giro Code
Line Edit (For Mixed Font Code Lines) and many more.
The amount of validation to be carried out by the reader would be
subject to user application requirements.
The data output format for verified and processed data is also a fully
user-programmable function.
The RS 232C communications interface parameters may also be
programmed to the users requirements.
(viii) Physical Specification
Dimensions (mm) 180(length) x 114(width) x 107 (height)
Weight 1.3Kg
Temperature 0°C to 40°C
Humidity 10% to 90% relative humidity
(b) Smart Card / Smart Key
Pathway would welcome discussions with POCL on the role that the
APPU could play in continuing to provide smart-card and smart-key
reading and writing capabilities at the counter.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 15 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
vind
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
(c) Options
Options that could be considered for the reader devices include :
(i) Advanced Multi Function Reader Module
Pathway are actively investigating the development of the advanced
Multi Function Reader Module. This uses the same basic reader
modules as described above in 4.5.5 (a) and also integrates additional
data capture functions as follows :
2D Bar Code Scanning (Including Royal Mail Code)
IC Chip (Smart Card) Reading/Writing
2D Bar Code Scanning
If there is a requirement to read two-dimensional bar codes, Pathway
would propose to interface a further bar code scanner to the Advanced
Multi Function Reader Module. Integration of a 2D scanner read
head into the Advanced Multi Function Reader Module would also be
possible, subject to standard positioning of 2D Bar Code symbols on
plastic card media.
The type of 2D bar code scanner to be integrated would be capable of
reading most 2D symbologies or those symbols recognised as industry
standards, including the Royal Mail Code. Power for the 2D code
scanner would be provided by the Advanced Multi Function Reader
Module or via a separate power adapter.
IC Card (Smart Card) Reader/Writer
The integration of an IC Card (Smart Card) Reader/Writer within the
Advanced Multi Function is under active consideration.
These developments would provide POCL with a single integrated unit
which meets all the card and document reader requirements and
occupies the minimum of counter space.
(ii) Advanced Hand Held Wand Reader
Pathway are investigating the possibility of a more advanced wand
reader which can read a wide variety of captured images including
OCR, CMC 7 font, machine printed characters (including typewriter
and line printer fonts), hand written numeric characters and other
printer characters.
The device, currently under development, is a small lightweight device
with a 15mm scanning window capable of scanning at 3cm to 20cm a
second.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 16 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
The technology that will be used in the wand devices will also be
available for integration into other devices including printers, PC’s,
document readers, etc.
4.5.6 BACK-OFFICE PRINTER
(a) Fujitsu DL3700 dot matrix printer
The DL3700 is a 24-pin dot matrix printer with a maximum printing speed
of 400cps. It will support up to DIN A3 paper and it incorporates an auto-
load function to simplify paper loading.
Resolution
Letter quality 360 x180 dpi
Correspondence 180 x180 dpi
Print Speed
Letter quality 120cps
Correspondence 240cps
Paper width 102mm to 267mm
Paper feed Bi-directional push/pull tractor
Auto cut sheet feed (2 bins)
Dimensions (mm) 133 (height)x434(width)x330(depth)
Weight 7Kg
Noise level less than 49dB(A)
(b) Options
Pathway can provide many varieties of back-office printer ranging from
matrix, ink-jet or page printers. The final choice will depend on the variety
of paper types that have to be supported, the print volumes and the range of
physical post office environments.
4.8.7 ISDN CARD
(a) Eicon ISDN DIVA
The Eicon ISDN DIVA card uses a Digital Signal Processor operating at
40Mhz. It supports the application interfaces CAPI 1.1 and CAPI 2.0
enabling very fine control to be exercised by the application over call
connection and network usage time.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 17 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
Cs 3
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
4.5.8 ADDITIONAL POST OFFICE OPTIONS
In addition to the hardware options identified above, Pathway recognises that
new business streams will also require additional counter peripherals. These will
include weigh scales and customer-facing displays and bar-code printers for a
Mails/Track&Trace application. Some large post offices may require a PC
configuration for local staff training or to run additional software packages.
The precise requirements of each individual or group of post offices will need to
be agreed with POCL.
4.5.8.1 POST OFFICE SECURITY
Pathway recognises the concern of Postmasters and the Federation of Sub-
Postmasters in the physical security of the post office. Pathway (including BT)
would welcome the opportunity of entering discussions with POCL to assess
how the POCL Strategic Infrastructure and supporting network might be utilised
to improve overall security.
4.5.9 SERVERS ON THE BACKBONE NETWORK
TMS will be configured across 4 sites with 2 or 3 racks of e.g. Compaq
ProLiant 4500R servers at each site, to provide full resilience. These will fulfil
the roles of correspondence servers, front-end processors (for ISDN Primary
rate connections), agents (for connections to external client systems) and system
management servers. They will each have very similar specifications, other than
their network connections. Considerable interchangeability is intended to
enhance the resilience of the backbone network.
(a) Correspondence Servers
The majority of the processors on the backbone network will be
correspondence servers. It is proposed that these be rack-mounted systems,
which have the advantage of a small footprint, and are designed for ease of
management and maintenance.
The racks measure 85” (height), 24” (width), 34” (depth) and weigh 227Kg
(for sample rack configuration with 3 servers, monitor, 60Gb disk storage,
DLT tape drive).
(b) Front-end Processors
Front-end processors will support, for example, Eicon $2M primary rate
ISDN connections via an EISA slot. In all other aspects, they will have
similar configurations to correspondence servers.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 18 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
cae ‘
ANNEX 4 - BASELINE PROPOSAL SUMMARY AND OPTIONS
(c) Agent Servers
Agents will connect to the backbone LAN and additionally to any specific
communications interface required to talk to particular client systems. The
hardware configuration will be similar to that of correspondence servers,
(d) Systems Management Servers
These will be used by the systems management team to monitor and control
server and network activities across the enterprise. The hardware
configuration will be similar to that of correspondence servers.
Technical Specifications (per Correspondence Server)
Processors 2 Pentium 100Mhz processors (expandable up to
4 per server, with migration to P6 processors)
Memory 128Mb (expandable from 64Mb to 1Gb of
advanced Error Checking & Correcting memory)
Cache 512Kb (expandable to 2Mb)
Architecture Compagq Triflex System Architecture
Internal Expansion 6 available EISA slots
Drive Controller SMART SCSI Array Controller (RAID)
Disk Storage 5 x 4.3Gb disk drives (expandable to over 300Gb
with additional bays in rack). Hot pluggable disks
are available.
Tape (e.g. back up) 10/20Gb Digital Linear Tape (DLT) - (one per
rack)
Backbone LAN 100Base-T fast Ethernet (standard Ethernet,
FDDI, Token Ring also supported).
Monitor & keyboard — One per rack
Operating System Windows NT
Operating Environment (per server)
Power Supply 540 watts (external Uninterrupted Power Supply
proposed)
Operating Temperature +10° to +35°C
Humidity 20% - 80%, non-condensing
Notes
Additional devices, such as an optical juke box (for archiving) and CD-ROM
may be provided on a per-site basis.
System monitoring and management tools, for instance Compaq Insight
Manager may be provided in addition to any enterprise-wide systems
management facilities (e.g. HP OpenView).
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 19 of 19
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ai S
ANNEX 5 - PATHWAY SECURITY POLICY AND APPROACH
TABLE OF CONTENTS
5. PATHWAY SECURITY POLICY AND APPROACH
5.1 INTRODUCTION
5.2 OBJECTIVES.....
5.3 RESPONSIBILITIES..
5.4 PATHWAY SECURITY STANDARD:
5.4.1 SUBCONTRACTORS .......0+0
5.4.2 PATHWAY'S RIGHT TO AUDIT.
5.4.3 OTHER DOCUMENTS.
5.4.4 LEGAL REQUIREMENT:
5.5 THE PATHWAY APPROACH TO SECURITY.
5.6 THREATS .......20000see00
5.6.1 TYPES OF THREAT
5.6.2 THREATS - BY WHO!
5.7 CONTROLS.....:.00+00e000
5.7.1 TYPES OF CONTRO
5.7.2 CONFIDENTIALITY...
5.7.3 INTEGRITY ..
5.7.4 AVAILABILITY.
5.7.5 AUDITABILITY .
ONOOOIAHUDAWWWNHNNPEPR EF
Pathway Response to COMMERCIAL IN-
OJEC Notice 94/S 165-58937/EN CONFIDENCE Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 5 - PATHWAY SECURITY POLICY AND APPROACH
5.
5.1
5.3
PATHWAY SECURITY POLICY AND APPROACH
INTRODUCTION
The purpose of this document is to give an overview of Pathway’s security
policy. The policy applies to Pathway itself and to all subcontractors employed
by Pathway for the purposes of supplying services to the Benefit Agency and
Post Office Counters Limited.
Each of the shareholders and subcontractors already has security policies, and
standards and practices in place. Therefore, it is inappropriate for Pathway to
impose security standards and practices upon them.
This document addresses Pathway's approach to security by concentrating on the
threats within the system and the methods that will be used to counter these
threats.
OBJECTIVES
The objective of the Security Policy document is to ensure that all parties are
fully aware of their responsibilities in relation to all elements of security as they
relate to Pathway and that they are aware of their legal obligations as they relate
to the provision of the Pathway service.
The Security Policy is a practical combination of the many years of experience in
computer and physical security of Pathway's principal shareholders (Girobank,
De La Rue and ICL).
Girobank’s parent company, Alliance & Leicester has had 25 years experience
of operations of a financial institution with its requirements for privacy and
security. De La Rue bring a strong tradition of security, emanating from their
background in security-printing of banknote, and other bearer documents, to the
security of card production. ICL has been involved in the provision of many
different types of service but their work with Government is particularly
relevant.
The objective of the Security Policy is to draw the best practices from each of
these companies and provide a coherent strategy tailored to the requirements of
the Pathway system. Particular emphasis has been placed on the need to secure
information as it flows from one secure environment to another.
RESPONSIBILITIES
The responsibility for the Security Policy and the related standards lies with the
Director of Quality and Risk Management who reports to the Managing
Director of Pathway.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 8
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 5 - PATHWAY SECURITY POLICY AND APPROACH
5.4
5.4.1
5.4.2
All parties, Pathway staff and subcontractors have responsibility for adheriung to
the Security Policy.
Each subcontractor will nominate a equivalent high-level person to be the day-
to-day contact on any matter relating to security. Each subcontractor has its
own Security Policy and related standards in place which will be audited by
Pathway to ensure compliance with Pathway's policy.
PATHWAY SECURITY STANDARDS
Pathway's security standards have been based on the Code of Practice for
Information Security Management issued by the BSI and the DTI. Additionally,
the security standards of each of the shareholders have been examined and best
practice assessed and applied to Pathway.
Particular emphasis has been placed on information that flows from one secure
environment to another and information that must exist in non-secure
environments, such as post offices.
Pathway is conscious that there is no such thing as 100% security and that the
security practices employed must be constantly assessed and updated. Pathway,
its shareholders and subcontractors, are dedicated to ensuring that the best
practice is used at all times and at all stages of the service.
The Director of Quality and Risk Management is a key member of the Project
Assurance Team (PAT) and is responsible for ensuring that appropriate security
measures are included in all system elements.
SUBCONTRACTORS
Every subcontractor has been advised of Pathway's Security Policy and has
agreed to abide by it.
PATHWAYS RIGHT TO AUDIT
Pathway has negotiated a ‘Right to Audit’ with each of the subcontractors and
will liaise closely with each organisation’s internal Audit department, where
applicable, or external auditors if their is no internal department.
Pathway acknowledges that BA/POCL will also have a right to audit and will
make any documents available to BA/POCL. Pathway will work in partnership
with BA/POCL to ensure that the Pathway service has, and continues to have,
the most appropriate levels of security in all of its elements.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 8
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 5 - PATHWAY SECURITY POLICY AND APPROACH
5.4.3 OTHER DOCUMENTS
Within Pathway, all personnel are given a copy of ICL's Information Security
Handbook and are required to assess the security of the systems and information
they are responsible for.
All personnel, either permanent or attached to Pathway, have signed a
confidentiality undertaking covering all work related to BA/POCL.
5.4.4 LEGAL REQUIREMENTS
Pathway, and its subcontractors, are aware of their legal obligations under the
following legislation :
* Data Protection Act 1984
* Copyright, Designs and Patents Act 1988
* Computer Misuse Act 1990
* EC Directive on Legal Protection of Databases 1993
Pathway recognises that further legislation will be introduced during the life of
the contract which may effect the provision of the service and/or the controls in
the service. Pathway wishes to assure BA/POCL that the requirements of any
such legislation will be introduced into the Pathway system in a manner that is
timely and cost-effective for all parties.
5.5 THE PATHWAY APPROACH TO SECURITY
Pathway's approach to security is to document and understand the threats
applicable within the system.
The scope, therefore is :
¢ Pathway Systems
¢ Subcontractors Systems
¢ The Links between Systems
¢ The Network both between Systems and to the Post Office Counters
* The Counter Terminals
* The Plastic Cards
The document concentrates on the controls necessary in the following three
basic security components :
* Confidentiality
¢ Integrity
¢ Availability
and addresses a fourth key element (Auditability) that will ensure that the
controls in the above three areas are in place and working correctly.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 8
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 5 - PATHWAY SECURITY POLICY AND APPROACH
To ensure that the policy is complete it is necessary to understand, and
document, the threats that exist, where they exist and the appropriate controls
that are to be used to prevent a breach of security in each of the areas.
Accordingly this document is structured to examine each of the threats, by type
and who could commit them, examine the methods available to ensure
confidentiality, integrity and availability, assess how an audit trail can be
provided for each of the security methods and document the types of control
and how they should be implemented in Pathway. The individual controls in
the system are not included in this document. Details of the controls used will
be made available to BA/POCL on a need-to-know basis.
Additionally, there are legal implications and we cover the relevant Acts, and
how they are addressed by this document.
5.6 THREATS
Before deciding on a security method to be used, it is essential to undertake an
assessment of the environment in which the system is going to reside.
At the simplest level, a system can be said to exist in either a hostile or non-
hostile environment. A hostile environment is one outside the control of
Pathway or Pathway's subcontractors and is generally in the public domain. The
terminals, their programs and data are in a hostile environment. A non-hostile
environment is one within Pathway's domain, or one of Pathway's
subcontractors’ domains, one where Pathway or its subcontractors can control
access to programs and data.
Some threats are therefore exclusive to a hostile domain and some are common
to both domains.
Against each of the types of threat listed below is an indication of the domain
affected.
5.6.1 TYPES OF THREAT
Listed below are the types of threat to which the Pathway service could be
subjected and where the threat could occur :
5.6.1.1 DATA THREATS
* Alteration of Data (Central, Network and Terminal)
¢ Addition of Data (Central, Network and Terminal)
* Deletion of Data (Central, Network and Terminal)
* Privacy of Data (Central, Network and Terminal)
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 8
OJEC Notice 94/5 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 5 - PATHWAY SECURITY POLICY AND APPROACH
5.6.1.2 EQUIPMENT THREATS
¢ Stealing Equipment (Central and Terminal)
* Substitution of Equipment (Terminal)
5.6.1.3 SYSTEM THREATS
* Denial of Service (Central and Network)
* Substitution of Software and Operating Systems (Central and Terminal)
¢ Hacking including Mimicking (Network)
* Sabotage (Central and Network)
¢ Collusion (Central and Terminal)
¢ Strikes (Central, Network and Terminal)
* Counterfeiting of Cards (Central and Terminal)
5.6.2 THREATS - BY WHOM
Many different classifications of people can commit acts that expose Pathway
and the Pathway service to threats. Listed below are the types of people who
can commit threats and the elements of the system exposed to that threat :
* Maintenance Staff (Terminal and Central)
¢ Network Staff (Network)
¢ Hackers (Network)
¢ Pathway Staff (Central and Terminal)
* Subcontractors Staff (Central and Counterfeiting)
* Post office Staff (Terminal)
* Sub Postmasters and their staff (Terminal)
¢ Franchisees (Terminal)
* Casual Staff (Terminal)
* Royal Mail Staff (Interception)
5.7 CONTROLS
There are many different types of control that can be employed to make a
system or system elements secure. Appropriate controls will be included in the
Pathway system. Listed below are the types of controls used. We also discuss in
this section where the controls are used and whether the control is applicable to
Confidentiality, Integrity, Availability or Auditability.
5.7.4 TYPES OF CONTROL
* Procedural (e.g. Recovery)
* Physical Security
¢ Access Controls
* Change Control Systems
* Staff Vetting
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 8
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 5 - PATHWAY SECURITY POLICY AND APPROACH
* Identification Systems
¢ Encryption and Authentication
* Secure Key Management System
* Back up Systems
* Contingency Plans
¢ Insurance
5.7.2 CONFIDENTIALITY
There are two principal methods of ensuring confidentiality : by restricting
access to those with a need to access the data, or by scrambling the data so that
it can only be read by a program or set of people with access to the encryption
keys. Both methods will be used in the Pathway system.
5.7.2.1 ACCESS CONTROLS
Access controls are primarily used in central systems and at terminals to ensure
that only people with the appropriate security clearance can access confidential
data.
5.7.2.2 ENCRYPTION
Encryption will be used primarily when data that must be kept confidential is
moved, usually by transmission from one secure environment to another.
Pathway is aware that there will be data held on central files that is sensitive and
file encryption techniques will be used for this data.
An encryption system is only as secure as its key management system.
Accordingly, appropriate controls will be in place to prevent access to, or
reading of, the keys used to encrypt data in transmission or on files.
5.7.3 INTEGRITY
Integrity applies equally to data and programs. It is pointless to protect the data
but allow the program to be changed so that the data protection is effectively by-
passed,
Data and program integrity can only be ensured by using a combination of
security methods and by ensuring, through regular audits, that the controls in
place are being followed.
§.7.3.1 PHYSICAL SECURITY
The first level of control will be physical security - denying access to any person
who is not cleared to enter an area where data and programs are kept. This
control is applicable at central sites and also at the terminal level if physical
locks are present on the machines.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 8
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
ANNEX 5 - PATHWAY SECURITY POLICY AND APPROACH
§.7.3.2
5.7.3.3
5.7.3.4
5.7.3.5
5.7.4
ACCESS CONTROLS
Access controls will be in place to ensure that only people with a need to access
programs or data can do so. For the central systems, file access and password
control systems are in general use in Pathway and its subcontractors. At the
terminal level, passwords are needed to access the system and, additionally, it is
impossible to break out of the application into native windows or DOS.
CHANGE CONTROL
All programs and standing data will be subject to change control procedures to
ensure that illegal code or amended data cannot be introduced to the system.
DATA AUTHENTICATION
Where appropriate, data and programs will be authenticated. That is a
cryptographic checksum will be computed, added to the data or program and
checked every time the data or program is used, This control will therefore
detect all illegal alterations to either data or programs. Different methods are
used; Cyclic Redundancy Checking at a record level, digital signatures generally
at a file or program level and encryption selectively applied at both record and
file levels.
It is understood that this form of control is only as secure as the key
management system employed and accordingly appropriate measures will be in
place to ensure the confidentiality of the keys used.
STAFF VETTING
Where appropriate, staff vetting is used to ensure that staff placed in a position
of trust are suitable for the purpose. The principal shareholders of Pathway all
have staff vetting procedures in place.
AVAILABILITY
Service availability will be a key requirement for BA/POCL. Accordingly,
controls, procedures and plans will be put into place to ensure that the service is
available according to the service level agreed. The Pathway service is built
around existing systems and services with a similar critical nature. Accordingly,
there are contingency plans in place to ensure continuity of service.
Similarly, the network option chosen provides redundancy and resilience to
allow the service to continue despite localised problems. The terminals have a
high mean-time between failure and a service level for replacement of parts of
the machine will be negotiated.
Pathway is confident that their controls will ensure availability of service.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 7 of 8
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 5 - PATHWAY SECURITY POLICY AND APPROACH
5.7.5 AUDITABILITY
The Pathway Security Policy mandates that an audit trail be included in the
system design from the development stage.
Pathway has negotiated a ‘Right to Audit’ for all system components run by a
subcontractor. The audit trails necessary for all the above controls are in place
and will be regularly checked by Pathway to ensure that the controls are
operating and are sufficient for the purpose. Pathway is willing, as a minimum,
to make their findings known to BA/POCL.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 8 of 8
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
TABLE OF CONTENTS
6.1 MINISTRY OF DEFENCE CHOTS PROJECT.
6.2 ITIN ICL - MAJOR CHANGE PROGRAM ..
6.3 INLAND REVENUE - SERVICE MANAGEMENT CENTR'
6.5 ALPS - ESNS (AUTOMATION OF LONDON POST OFFICES)
6.6 POSTBANK (GERMANY)
6.7 BA PROJECT.........
6.8 VISA CALL CENTRI
6.9 ALLIANCE ACCOUNT
6.10 GIROBANK - LEGAL INTEGRATION
BHEBRoNawE
6.12 AN POST COUNTERACTION CASE STUDY.
6.13 VICTORIA WINE ..
6.14 J SAINSBURY - TOTAL MANAGED SERVIC!
6.15 CARDLINK (IRELAND) .........0+2++
6.16 DE LA RUE CARD TECHNOLOGY
SoMOnTund
w&
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
6.1 MINISTRY OF DEFENCE CHOTS PROJECT
DATE : OCTOBER 1991
CLIENTS : MINISTRY OF DEFENCE
ANNUAL VALUE: £50M
CONTRACT ATTRIBUTES RELEVANT TO THE RESPONSE
* System development
* Systems integration
+ Implementation of change
¢ Support and help desk facilities
¢ Supplier collaboration
CONTRACT TERMS
The Ministry of Defence procurement programme for secure office automation began in the
mid-1980s and in 1988 TOPIX, the ICL-led consortium, won one of two pilot contracts.
- Following successful implementation of its pilot system, TOPIX won the full contract in
October 1991.
BUSINESS OBJECTIVES
CHOTS is an MoD project to equip 18,000 MoD Corporate Headquarters staff with a
terminal or workstation giving them full secure office automation facilities and access to other
local and corporate applications systems.
DESCRIPTION OF TASK
The scope of the CHOTS contract comprises development and supply of the systems, their
operation, support and maintenance, user training and user support, and all associated project
management. The initial contract value was £250m of which 70% is services.
The TOPIX consortium was formed in 1987; it comprises ICL, Hewlett Packard, Coopers and
Lybrand, BICC and Data Logic.
Effective management of the consortium was crucial to the delivery of the successful pilot.
The consortium, under the prime contractorship of ICL, operated as a single entity with its
own corporate identity (TOPIX), its own management team and headquarters.
The working relationships thus established proved a major strength, particularly when the
pilot system went through periods of stress, as expected, and extra effort was needed to keep
to the plan.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
Sng Ge
ANNEX 6 - PATHWAY CASE STUDIES
The consortium worked closely with a subset of the customer's project team to identify the
technical challenges and the business objectives. Both parties accepted from the start that the
activities were only to be part-funded and that one objective was to refine the requirements,
before roll-out to 20,000 or so desks.
The project was the first implementation in the world of a secure UNIX system supporting an
office infrastructure and mounted across several platforms. It required technology initiatives
of the highest order, but also capabilities within the consortium and the customer's team to
handle the management of change issues which were quite substantial in the culture then
prevailing.
Today the consortium is unchanged, and there is a close relationship between the parties at all
levels from UK Director downwards.
The CHOTS project currently covers 12 MoD locations in the South of England. The
CHOTS programme is on time and budget, and to date has nearly 7,000 live users on 160
distributed systems.
The service covers all aspects of the provision of secure office automation, including system
development, system operations, security, support provision, networking, configuration
management, staff training, system changes, staff moves and maintenance.
The CHOTS project has an annual release policy where a package of various tailored products
are combined to provide a stable system. Typically this includes versions of UNIX, office
automation software, communications and hardware, all of which will have been altered to
meet the MoD's specific requirements for security and functionality. The project will also
develop supporting functions such as training, data conversion and documentation to ensure
that the changes are implemented efficiently and effectively.
BUSINESS BENEFITS
* Single secure interface to all systems
* 15% saving on staffing and IT costs
¢ Staff movement flexibility
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ic: 2
ANNEX 6 - PATHWAY CASE STUDIES
6.2 IT IN ICL - MAJOR CHANGE PROGRAM
DATE : 1991
CLIENTS : ICL PLC - WORLDWIDE
VALUE : N/A
CONTRACT ATTRIBUTES RELEVANT TO THE RESPONSE
* Managing major change over a large user population
* Managing regular change
* Managing change over a wide geographic distribution
* Outsourcing of internal IT
CONTRACT TERMS
The responsibility for the delivery of the systems that support ICL’s information requirements
rests with the company’s own, internal information technology group, “IT in ICL”. This
group delivers IT services to the various functions of ICL.
A change programme began in early 1991, with initial studies establishing a set of underlying
principles upon which the major change programme would be based. The result is an
implementation of these principles and a fundamental re-organisation of the way in which IT
in ICL provides its services to ICL plc. Services are now provided to each of ICL’s Business
Divisions by the Group Outsourcing Division.
BUSINESS OBJECTIVES
ICL recognised that effective IT operation management was a key driver in ensuring that an
increasingly successful and competitive market position was maintained.
At the same time, investment in Information Technology and Telecommunications within ICL
was considered to be excessive and unquantifiable in terms of business benefit. The challenge
was to create an IT environment that better supported (measurably) the company's strategic
objectives (such as business unit autonomy), but was able to provide the required range of
services based largely on existing resources and a more realistic budget.
DESCRIPTION OF TASK
The efficient delivery of internal management information is crucial to the smooth running of
ICL’s current operation and its future success. The company realised that the full potential of
its human and technical resources was not being realised under the existing IT structure.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
ICL has had to absorb radical changes in customer demands for products and services, vertical
alignment between ICL and its suppliers and integration of operations with those of Nokia
Data, Technology plc and Sorbus. Such changes could only be managed successfully in an
environment where immediate and accurate information is readily available. IT in ICL was
aware that meeting the twin challenges of providing an improved service for its client and
reducing its excessive expenditure could only be addressed by the implementation of a major
change programme. This programme would have two key objectives :
* To establish an organisational structure and technical environment within which all
information required in ICL could be delivered electronically
¢ To create an IT infrastructure for ICL from which competitive advantage could be gained,
by more effective and efficient business processes, providing a fully integrated supply chain
for products and services
Particularly affected would be the approach to systems provision. The key principles, adopted
as critical success factors for the change programme, were as follows :
* To gain tighter control over application development, integration and support activities
* To implement end-to-end management of application services with measurement of the
performance experienced by the end users
* To achieve tight management of the telecommunications services, including voice, data and
video links, provided over the ICL worldwide network
* To gain acceptance of Business Process Re-engineering and the need for more effective
process support as the catalyst for any change in information systems
* To use quantifiable business benefit or improved customer satisfaction as the only
justification for any application development or change
* To gain corporate commitment to Business Process Management, Electronic Trading and a
commitment to implement the recommendations of ICL's strategic business report
* To implement remote application management and telecommunication service management
facilities
The group's business practises were redrawn by three functional teams and a systems approach
developed which responded to the strategy of focusing delivery on the end users of systems.
BUSINESS BENEFITS
* Greatly increased productivity of IT in ICL's staff
* Realignment of IT towards support of business processes
* Technical performance has improved quantifiably
* Reduction in application development time
* Improvement in user satisfaction
* A saving in operating costs of £25m in three years
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
6.3 INLAND REVENUE - SERVICE MANAGEMENT CENTRE
DATE : APRIL 1986
CLIENTS : INLAND REVENUE
VALUE : N/A
CONTRACT ATTRIBUTES RELEVANT TO THE RESPONSE
¢ Use of automation
¢ Efficiency through rationalisation
¢ Management of distributed environment
CONTRACT TERMS
The IRSMC was set up by ICL in April 1986, at the request of Inland Revenue, to provide a
dedicated single point of contact for the co-ordination of all ICL engineering and software
support services to Inland Revenue. This has been extended for a seven-year period as of
October 1992.
BUSINESS OBJECTIVES
The IRSMC assigns a priority category for all reported problems commensurate to the impact
of the problem and manages the reported problem for the entirety of its life-cycle. The task
demanded a high level of control for which a call management system, CALCAM, was
developed.
DESCRIPTION OF TASK
The IRSMC is a managed support service provided by ICL and is an integral element of the
Inland Revenue support infrastructure. All relevant problems are reported to the IRSMC help
desk, and logged on CALCAM via the Inland Revenue Problem and Inventory Management
System (PIMS). This process has been in place some six years and has successfully managed
some 25,000 hardware and software incidents annually.
Using the CALCAM system, the IRSMC assigns a priority category for all reported problems
commensurate to the impact of the problem and manages the reported problem for the
entirety of its life-cycle.
This problem-management activity includes notifying and co-ordinating the appropriate
support authority to ensure the necessary support resources are made available to resolve the
problem.
CALCAM will escalate the calls according to the SLAs in place, adhering to the escalation
procedures when necessary.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STU
Since its inception the IRSMC has reduced the call-to-fix time for incidents in the network,
resulting in increased overall IT systems availability.
Through monitoring and managing the response to all Inland Revenue service calls, CALCAM
maximises availability of service to Inland Revenue's end users.
Some of the functions provided by CALCAM are set out below :
Passing all calls on to the appropriate service provider
Notifying ICL Customer Service via the ICL call management system of all installations and
upgrades
Producing statistical and management measurements of the service supplied by ICL to
Inland Revenue
Provision of a consistent value added service performed to quality procedures audited to BS
5750/ISO 9000 standards
BUSINESS BENEFITS
The use of an automated system at the IRSMC has resulted in the following benefits :
°
Reduced cost of administration
Faster call resolution leading to improved end-user efficiency
Configuration control of software leading to less incidents
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
6.4 CAMELOT
DATE : 1994
CLIENT : OFLOT
ANNUAL VALUE : £130M
CONTRACT ATTRIBUTES RELEVANT TO THE RESPONSE
* Systems integration
¢ Installation and commissioning
* Recruitment and training
* Supplier collaboration
CONTRACT TERMS
ICL is part of the successful Camelot consortium selected by the UK Government to manage
the National Lottery. The consortium is responsible for running the Lottery and providing
and maintaining the infrastructure with which to run it.
BUSINESS OBJECTIVES
OFLOT expects to have two thirds of the UK population participating in the UK National
Lottery, thus making it the biggest lottery in the world.
By the end of 1996, nearly 40,000 retail outlets will be selling Lottery tickets, including
corner shops, petrol stations, confectioners, newsagents and post offices throughout the
country.
DESCRIPTION OF TASK
The Camelot consortium comprises De La Rue, Cadburys, GTech, Racal, and ICL. ICL holds
a 10% stake in the company formed for the Lottery, sat on the original steering committee
and was a prime co-ordinator in producing the business plan.
Camelot plans to have a ticket outlet for every 1,500 people, and four out of five people
should be within 2 miles of a ticket sales point.
In this major programme management and logistical exercise, ICL has responsibility for
building and installing the terminals, training retailers and recruiting staff for the Camelot
company.
The infrastructure for the National Lottery is being installed by ICL to challenging timescales.
From award of contract to the first prize draw was just 25 weeks.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 7 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CA
2 STUDIES
In this time 500 staff needed to be recruited by ICL to run the Lottery infrastructure, 11
regional offices and two central computing centres needed to be installed, 31,500 specialist
ticket terminals had to be manufactured and these are currently being installed by ICL at a rate
of 2,000 per week. In addition 30,000 retailers were trained in the use of the equipment in
just five weeks and this was organised at 180 locations across the UK.
BUSINESS BENEFITS
* 1st prize draw 25 weeks from award of contract
* Optimum mix of specialist suppliers
* Consortium shares OFLOT's risk on the project
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 8 of 32
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
ANNEX 6 - PATHWAY CASE STUDIES
6.5 ALPS - ESNS (AUTOMATION OF LONDON POST OFFICES)
DATE : JANUARY 1995
CLIENT : POST OFFICE COUNTERS LIMITED
ANNUAL VALUE : £9M
CONTRACT ATTRIBUTES RELEVANT TO THE RESPONSE
* Significant roll-out over short time period
* Integration of many different hardware components
¢ Iterative software development
CONTRACT TERMS
Post Office Counters Ltd. (POCL) placed a contract with ICL Enterprises on 23rd January
1995 for the development, implementation and service of the Electronic Stop Notice System
(ESNS) to run on 4,500 PCs in 1,500 post offices within the London area.
BUSINESS OBJECTIVES
* Achievement of the required fraud-reduction targets by meeting the challenging deadlines
for systems implementation
* Delivery of systems based on a modular architecture, designed and built to preserve the
significant financial investment in hardware and software
* Implementation of systems that encourage rapid user acceptance and minimum business
disruption
DESCRIPTION OF TASK
The system included the provision of bespoke applications software, PC hardware, bar code
readers, printers, other associated peripherals, and associated delivery, installation and
maintenance services.
The requirement was to begin roll-out of the systems to the post offices beginning on 24th
April 1995 with total implementation due for completion on 6th August 1995. At this stage,
the project is on track to meet these dates. At the maximum rate, ICL will install 550 systems
in one week.
The success of the project to date has been due mainly to the excellent partnership approach
developed between POCL and the ICL project team.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 9 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
LON. fk a
ANNEX 6 - PATHWAY CASE STUDIES
BUSINESS BENEFITS
Already, following installation of over 400 offices, ESNS is delivering real benefit to the
Benefit Agency in terms of identified fraud and the return of benefit books for amendment.
The installed systems are future-proof and will be used as part of Pathway’s implementation of
the main systems.
The system has received very positive acceptance from the users due to its very simple and
‘friendly’ user interface. The aim in design was to make the system intuitive to the user. This
is proving to be the case with only minimum user training necessary.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 10 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ie ; &
ANNEX 6 - PATHWAY CASE STUDIES
6.6 POSTBANK (GERMANY)
CONTRACT AWARD : 1991
CLIENT : GERMAN POSTBANK
TOTAL VALUE : N/A
CONTRACT ATTRIBUTES RELEVANT TO THE RESPONSE
« Large-volume card manufacture, card personalisation, PIN generation, PIN mailer printing
* Card design and plastic proofing
* Hologram design, origination and supply
* Secure card despatch to bank branch
* Secure PIN mailer distribution to cardholders
* 100% audit trail of production and despatch processes
* High-security production facility (internationally approved security licences)
* Daily liaison with the PostBank’s Card Management Service
* Product produced in a language other than English
CONTRACT TERMS
In 1991 the German PostBank required the services of a company to provide a complete range
of card-making and personalisation services. The contract required De La Rue Card
Technology to manufacture and personalise 3.5 million cards over 23 weeks, as well as
generate and print the PINs for each cardholder.
BUSINESS OBJECTIVES
PostBank needed to provide its customer cardbase with approximately 150,000 personalised
cards and PINs per week. The objective was to achieve cost savings and service benefits by
dealing with a single supplier capable of providing the complete end-to-end service for all
card-related products.
DESCRIPTION OF TASK
De La Rue won this major full-service contract against local competitors who argued that a
company manufacturing and personalising cards in England for the German market would fail
to match the strict delivery schedules and quality levels demanded. In addition to the card
production, the contract also demanded the following requirements :
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 11 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
tad
ANNEX 6 - PATHWAY CASE STUDIES
(a) Secure PIN generation and PIN mailer printing
The PIN production processes required De La Rue to carry out these two activities in
strict accordance with the security procedures and time schedules stipulated by the
PostBank. The despatch of printed PIN mailers to Germany needed to be closely co-
ordinated against the despatch of live cards.
(b)
Hologram Design, Origination and Supply
De La Rue was able to call on its industry-renowned holographic capability (De La Rue
Holographics) to design, originate and supply a security hologram for the PostBank card.
The security hologram produced by De La Rue greatly increased the cards’ resistance to
counterfeit.
(c) Sourcing of Stationery Items
De La Rue needed to source and maintain adequate stock levels for the stationery items
(card carriers, envelopes, inserts and PIN mailers) required for the contract. The printed
information on these items was in German and De La Rue had to ensure that any changes
in the text or design were accommodated in a timely manner.
CONCLUSION
To meet the challenges of this project, De La Rue increased its staffing levels and extended the
production capacity accordingly. Day-to-day communications with PostBank were conducted
in German by De La Rue’s project team. The logistical problems of supplying personalised
cards to PostBank branches and printed PIN mailers to cardholders on time were resolved by
working closely in partnership with the secure transport providers and by improving the
internal despatch processes used by De La Rue.
BUSINESS BENEFITS
* Single source supply for a complete range of card manufacturing and personalisation
services
* Efficient and secure delivery of items to branches in accordance with an agreed schedule
* Service and quality which PostBank could pass on to their customers
* Flexibility to change the card issue program (increase production capacity and stationery
items)
* Supplier capable of providing a migration path to new card technologies
* Ability of supplier to reduce fraud costs by having access to new security features
* Minimisation of the risk by using a high-security and stable supplier who is internationally
approved
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 12 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 WAY CASE STUDIES
6.7 GIROCHEQUE RECONCILIATION PILOT
CONTRACT AWARD : 1992
CLIENT : BENEFIT AGENCY
TOTAL VALUE : N/A
CONTRACT ATTRIBUTES RELEVANT TO THE RESPONSE
* Cash Account reconciliation
* Provision of management information for Benefit Agency cheque encashment
* Pilot proving capability
CONTRACT TERMS
A system that provides the processing, reconciliation and settlement figure for all Benefit
Agency cheques cashed at post offices in England Scotland and Wales. A number of critical
factors contributed to the success of the project. One of which was to provide the Benefit
Agency with the facility to run a parallel pilot process with the bank from initial capture of the
cheques to the production of fully auditable reconciled settlement accounts.
BUSINESS OBJECTIVES
* Reduce reconciliation timescales
¢ Improve management information
¢ Improve customer service
DESCRIPTION OF TASK
The following key elements formed the pilot plan :
Conversion of historical and unreconciled issues and encashments at an agreed point
Receipt of issue information for all girocheques issued in England, Scotland and Wales
Receipt of all girocheques encashed in Wales
Joint capture and reconciliation of all girocheques for post offices in Wales
The production of fully auditable settlement accounts
Production of the Benefit Analysis and its reconciliation to the DSS (Master) version
Liaison with National Audit Office to confirm NAO outputs from Girobank system
oe eee ee
The pilot ran for a period of five months, during which a number of cash account weeks were
fully reconciled and the bank was able to prove the integrity of its Benefit Analysis to the
satisfaction of Benefit Agency.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 13 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
Implementation was based on a clean-down of the Girobank system with all data being
reloaded as at an agreed point. Benefit Agency undertook work prior to conversion to clear
down.
BUSINESS BENEFITS
© Complete reconciliation of Benefit Agency cheque payments
* Improved funding and settlement
* Improved accounting
* Reduced costs
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 14 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
SB
ANNEX 6 - PATHWAY CASE STUDIES
6.8 VISA CALL CENTRE
CONTRACT AWARD : 1994
CLIENT : A&L (INTERNAL)
TOTAL VALUE : N/A
CONTRACT ATTRIBUTES RELEVANT TO THE RESPONSE
* Creation of call centre
* Use of latest telephone technology help desk
* Change management
MAIN FEATURES OF CONTRACT
* Creation of a call centre and help desk
* Production and delivery of large volumes of plastics and stationery
¢ Interface to numerous Group systems as well as outside agency systems
* Recruitment and training of suitable personnel
* Set-up and management of various databases
* Enhanced telephone technology, for example, ACD, voice response, power dialling
DESCRIPTION OF TASK
The Visa operation was originally launched in 1988 to enhance the Personal Banking
function’s (pre-legal integration) range of products and services. Prior to the launch of our
Visa call centre in 1994, the main focus was almost exclusively on productivity, increasing
throughput and driving down costs.
However, although the introduction of the annual fee lifted the Visa operation into profit, we
were seeing a reduction in our customer base, partly as a result of new players introducing
themselves to the Visa card market with aggressive pricing policies.
It was recognised that building strong customer relationships would ultimately provide a
profitable and loyal customer base and this was to be achieved by developing a staff focus on
service, efficiency and customer care which would be complemented by customer-retention
and cross-selling initiatives.
Although Visa had an established centre on Merseyside, with a cardholder base and an
established workforce, the call centre was designed and built from scratch, with much more
emphasis placed on servicing via the telephone. New methods and cultures had to be
developed, which meant replacing existing staff with new people capable of providing the
skills that would be required in the new call centre.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 15 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
The call centre manages a card base of approximately 300,000 customers, and is staffed by 49
FTEs which is set to rise to 62 FTEs. Total call traffic from launch of the call centre in April
1994 to the end of that year was 685,277.
A major task associated with the information call centre was to introduce a change of culture
and focus into the area. It was a major personnel issue to replace existing staff with new call
centre staff. To complement the new focus, the new area had to be completely refurbished
with new carpets, workstations and lighting, all within tight timescales.
The development of the call centre was in progress at the same time that preparations for legal
integration were being formulated and this meant that key personnel had to be involved in
both of these projects, and that a massive card-replacement programme had to take place soon
after the call centre was opened.
Training of new staff was very intensive and had to be specifically geared towards customer
service, cross-selling, customer retention and product knowledge. This also involved the
development of new operating procedures, all designed to BSI standards and this process
alone had to be very carefully co-ordinated and controlled.
Customer perception of the new initiative was also a complex issue because the initiative was
designed to benefit them. The improved levels of service were an obvious benefit but
customers became direct targets for outbound selling and customer loyalty initiatives, a new
experience with potentially negative consequences.
Finally, and probably most complex of all, there were many different functions which helped
to support the operation of the call centre such as lost and stolen stationery, authorisations
from retail outlets and debt collection areas. There was a requirement to know the workings
of other available Group account management systems in addition to the many and varied Visa
International operating rules and regulations.
BUSINESS BENEFITS
¢ Improved culture
¢ Improved customer focus
¢ Improved customer retention
¢ Enhanced cross-selling opportunities
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 16 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
6.9 ALLIANCE ACCOUNT
CONTRACT AWARD : 1993
CLIENT: A&L (INTERNAL)
TOTAL VALUE : N/A
CONTRACT ATTRIBUTES RELEVANT TO THE RESPONSE
* Innovation
* Service creation
* Systems integration
MAIN FEATURES OF CONTRACT
* Unique distribution system via call centre/branch/post office counters, ATMs and the post
* Full banking facilities including cheque books, cheque cards, debit cards, standing orders
and direct debits
* 24 hours per day, 365 days per year opening, manned by a dedicated team of staff
* The availability of other Group services, on a one-stop-shop basis, for example, fund
transfers, personal loans and Visa cards
BUSINESS OBJECTIVES
To develop a flagship current account aimed at the customers of the Alliance & Leicester
Building Society
DESCRIPTION OF TASK
The new account needed to be developed from scratch, within 12 months, with the necessary
systems and infrastructure in place to support a national TV launch and the anticipated growth
targets (in excess of 50,000 new accounts ledgered within six months).
From one call centre we needed to handle everything from account opening, literature
fulfilment and account procurement through to ongoing account management. The
infrastructure needed to be sufficiently robust to handle in excess of 25,000 calls per week
within the first few months, with quite significant peaks of traffic because we responded in
real time to television advertising of our hot-line numbers.
BUSINESS BENEFITS
* Strategic product development
* Key customer relationship vehicle
* Business development platform
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 17 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
6.10 GIROBANK - LEGAL INTEGRATION
CONTRACT AWARD : 1993
CLIENT : A&L (INTERNAL)
TOTAL VALUE : N/A
CONTRACT ATIRIBUTES RELEVANT TO THE RESPONSE
* Management of change
¢ Systems integration
CONTRACT TERMS
In January 1993 the A&cL Board gave approval to progress the strategy for optimising the
strengths of the different parts of the group. The nucleus of this strategy was to create a
single, broadline personnel financial services business complemented by a unique corporate
business. To achieve this aim it was necessary to legally integrate the Personal Bank into the
Building Society.
BUSINESS OBJECTIVES
To integrate the Personal Banking arm of Girobank with the Personal Financial Services
division of the A&L Building Society.
DESCRIPTION OF TASK
The project was successfully implemented on time on 1st May.
Despite significantly underestimating the volume of stationery and card orders during the first
month of operation, both our internal systems and our key suppliers managed to handle the
volumes within the agreed service-level targets.
The implementation of the main project addressed the re-issue of stationery and plastics to
customers who needed new suppliers but did not consider the low-usage customers who did
not require new stationery before 30th April 1995.
In October 1994, there were still 400,000 cheque books and cards to be issued. Processes
were written, tested and released which ‘drip-fed’ these items to our suppliers in a manner
which guaranteed that we would meet the deadline imposed by the Bank of England, whilst
maintaining the service-level targets with our suppliers.
This exercise was completed by March 1995 and the project has now been formally
completed.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 18 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
.
On implementation (1st May 1994) all customer correspondence (letters, statements and
leaflets) had to bear the new brand/owner name
The different Group brandings had to be discreet with no possibility of errors
In accordance with Bank of England requirements, 1.2 million plastic cards and cheque
books had to be re-issued before 30th April 1995
The assets on the balance sheet had to be correctly apportioned between PFS and Corporate
Bank as at Ist May 1995
The profitability reporting for Personal Banking had to be transferred before 1st May 1995
To successfully deliver this project in a limited time period, it was essential to create a project
structure that included all the affected areas of the Group but was not so large that it became
unmanageable. This was achieved by creating a clearly focused steering committee and
control group, with various sub-groups (such as communications, testing, implementation) set
up with the authority to take action on the day-to-day project issues.
BUSINESS BENEFITS
Strategic alignment of customer base
Enabler for cross-selling of Group products
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 19 of 32
OJEC Notice 94/5 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
6.11 BRITISH GAS BILL PAYMENT SERVICE
CONTRACT AWARD : 1994
CLIENT : BRITISH GAS
TOTAL VALUE : N/A
CONTRACT ATTRIBUTES RELEVANT TO THE RESPONSE
* The Partnership approach
* Business development with POCL
CONTRACT TERMS
In the summer of 1994, Post Office Counters Ltd. (POCL) and Girobank identified an
opportunity for both organisations to work together to satisfy market demands for a complete
Bill Payment Service.
POCL had for some time been developing an Automated Payment option at the counter using
a plastic card issued to the end consumer. Some success had been achieved in selling the
service to the Utility market.
Girobank already offered Transcash as a means of paying bills at post offices and was also able
to complement this with the ability to collect payments made by direct debit or standing order.
As a consequence, facilities were already in existence for a number of the Utility companies.
By approaching the target market as a partnership it was believed that a complete package
could be made available, thereby offering the potential for entire revenue collection.
Having made the decision, the partners were faced with an immediate challenge as the
opportunity to deliver such a service for British Gas arose within a matter of weeks. The
challenge was increased further when a delivery date was requested for the third quarter of
1994,
BUSINESS OBJECTIVES
To provide a complete Bill Payment Service in partnership with POCL.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 20 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
v al
ANNEX 6 - PATHWAY CASE STUDIES
DESCRIPTION OF TASKS
During early discussions, relationships and joint groups formed at senior level in order to
identify a shared vision. In order to deliver the complete service it was necessary to bring the
two organisations together at the operational and development levels. A complete formal
structure was adopted to oversee marketing, development and implementation activity.
To satisfy the requirements of British Gas, a joint implementation team was created involving
technical and managerial staff from both organisations and customer representatives.
Clear roles and responsibilities within the joint team were agreed and structured plans were
formulated in order that all parties (including British Gas) could identify what was expected of
them, and the dependencies. As British Gas was to be the first customer to make use of the
service, building an infrastructure between Girobank and POCL had to be included within the
plan and completed to the same timescales.
Regular and frequent liaison between Girobank and POCL staff at all levels generated a clearer
understanding of each other’s individual and collective needs and abilities. Because of the
limited timeframe available to satisfy British Gas, this understanding was essential to our
success.
It is an undoubted credit to both organisations and their collective ability that the service was
delivered to British Gas in accordance with the agreed specifications and timeframes. The
Transcash Service went live with effect from 31st May 1994 and the Automated Payment
Service from 16th August 1994.
BUSINESS BENEFITS
The joint expertise developed between the two organisations to deliver this service to British
Gas has subsequently been used to generate additional benefit for both partners and create a
joint identity under the ‘Collections Connections’ banner.
Five further Utility customers have been implemented onto the same service, each having its
own specification and development plan. These existing customers are :
* Eastern Electric
* Severn Trent Water
* South West Water
¢ Welsh Water
* Yorkshire Water
Further Utility customers are now being implemented and additional market opportunities
identified are being jointly explored and developed. Further implementations are scheduled
for these additional customers :
* Seeboard
* MEB
* South East Water
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 21 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
K jal
ANNEX 6 - PATHWAY CASE STUDIES
* Mid Southern Water
¢ North West Water
¢ Birmingham Cable Communications
* Teesside Cable
* Glasgow City Council
The Bill Payment Service is a singular example of how Girobank and POCL are able to work
together at all levels, identify market opportunities efficiently and effectively, develop services
and facilities to meet those opportunities and deliver the services to the end customer. The
level of understanding that has developed between the staff of the two organisations is of
significant and undoubted value. This has clearly been a significant factor in the success of the
partnership approach. Whether either party could have achieved this success single-handedly
is less certain.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 22 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 6 - PATHWAY CASE STUDIES
6.12 COUNTERACTION CASE STUDY
CONTRACT AWARD : 1992
CLIENT : AN POST
TOTAL VALUE : N/A
CONTRACT ATTRIBUTES RELEVANT TO THE RESPONSE
* Counter infrastructure
* Roll-out
* Partnership with clients
¢ Support services
* Business development
MAIN FEATURES OF CONTRACT
* Develop retail sales ability
* Advance its customer service standards
CONTRACT TERMS
An Post wanted a stable, flexible systems platform to enable front-office applications to be
gradually expanded and their functionality increased.
BUSINESS OBJECTIVES
* Increase counter productivity
* Reduced transaction time and cost
* Enable marketing of retail and financial products
* Enable take-on of new business streams
* Reduce administration and accounting time
DESCRIPTION OF TASK
The first step was to overcome information processing ‘bottlenecks’. The problems included
an unacceptable average length of transaction times at counter positions, a lack of information
for counter customers and the absence of an An Post system that could be integrated with
those of agency customers. An Post also recognised that outmoded methods of transaction
handling, rising costs and increased competition was eroding its counter business.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 23 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
A
ANNEX 6 - PATHWAY CASE STUDIES
After in-depth evaluation of the major operating systems, An Post chose a PC-based solution
built around Microsoft’s Windows for Workgroups 3.11 and Microsoft Windows NT. It was
designed to overcome the bottlenecks, remove the complexity associated with traditional
computing applications by ensuring the system was easy to use for staff and provided enough
counter and central processing power.
From a total of 2,000 post offices, An Post selected its top 600 for a phased implementation
of the automation programme, known as CounterAction. The post offices are both large and
small and are geographically spread, and they will be automated over a four-year period. The
basic building block of the CounterAction front-office system is Windows for Workgroups
3.11. Above it sit modular product application sub-systems which can be added or changed
over time. It offers superior performance to comparable platforms by supporting full 32-bit
file access to information and 32-bit networking.
Every post office counter position has a networked Intel 80486-based PC. One PC in each
post office acts as a communications workstation, sending and receiving data via X.25-based
star topology leased circuits, feeding into regional nodes linked to An Post’s headquarters.
An Post also standardised on Microsoft Visual Basic as the programming tool for applications
in CounterAction. An Post developers can easily create and enhance each front-office
application according to the specific design criteria and set of functions needed using Visual
Basic’s own built-in database engine. It supports data sharing and messaging in programming
workgroup applications, plus its capacity for re-using software components gives An Post a
highly productive development platform.
BUSINESS BENEFITS
Joe Cosgrave, Head of Development, Financial Services, says : “An Post’s Counters Business
fulfils a key strategic role nationally. For example, today we act as the processing agents for
many of the country’s social welfare payments. CounterAction is the vehicle by which we can
improve the level of job satisfaction internally. An expanded range of agency, customer and
An Post products can also be added without major re-engineering. This means greater synergy
between our future plans for ‘across the counter’ products and the counter business.”
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 24 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
6.13 VICTORIA WINE
CONTRACT AWARD : 1993
CLIENT : VICTORIA WINES
TOTAL VALUE : N/A
MAIN FEATURES OF CONTRACT
* Cost effectiveness
* Electronic point of sale (EPOS)
* Voice telephony
* Electronic Mail
CONTRACT TERMS
Until December 1993 Victoria Wine had a modem-based system connected to approximately
1000 outlets via the analogue public switched telephone network. The system was slow,
prone to operational difficulty and was not realistically capable of expansion to the remaining
outlets.
DESCRIPTION OF TASK
To improve cost-effectiveness Victoria Wine decided to replace the existing analogue network
with one based on ISDN delivered by BT. This change offered Victoria Wine the advantage
of delivering all its telecommunications requirements (EPOS, voice telephony and electronic
mail) via a single service platform. EPOS transactions involving bank and credit cards are now
completed significantly faster.
With ISDN, information retrieval that had previously taken over three hours per 1000 lines
now takes 1.5 hours for 1600 lines. ISDN also permits the continual monitoring of shops
connected to the network so that potential problems can be detected and quickly rectified.
BUSINESS BENEFITS
Victoria Wine has a total of 1600 shops, including the Augustus Barnett chain, and a number
of other licensed trade outlets.
Victoria Wine now plans the complete integration of telephony-based requirements to all its
outlets; a total of 3000 ISDN lines delivered from BT, by September 1995. It is also
considering future applications such as slow-scan TV and integration of alarms.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 25 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
6.14 J SAINSBURY - TOTAL MANAGED SERVICE
CONTRACT AWARD : 1994
CLIENT : J SAINSBURY PLC
TOTAL VALUE : N/A
CONTRACT ATTRIBUTES RELEVANT TO THE RESPONSE
* Support and help desk facilities
* Wide geographic distribution
* Collaboration with other suppliers
¢ Partnership with our client to implement change
CONTRACT TERMS
Sainsburys is one of the United Kingdom’s largest and most successful supermarket chains,
with approximately 350 branches spread throughout the country. In 1994 ICL was awarded a
contract to provide a Total Managed Service for their IT.
BUSINESS OBJECTIVES
Sainsburys recognised the business benefit of placing a single contract for the support of all IT
within its retail outlets thus simplifying the interface for service issues and reducing
management time and responsibility identification.
Secondly, through implementing a preventative maintenance policy Sainsburys achieved
improved utilisation and ICL benefited from less re-active maintenance calls.
DESCRIPTION OF TASK
ICL provides a Total Managed Service to help ensure that Sainsburys’ IT infrastructure
continues to provide the levels of service required to support their business.
This service covers the following systems :
* Point of sale terminals
* Petrol pumps
¢ Weigh scales
« In-store systems including UNIX servers
¢ In-store, high-speed Local Area Networks
The service provides Sainsburys with a single point of contact for notifying and monitoring all
incidents that require support.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 26 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
The central point of contact is provided by the ICL Call Reception Centre in Wakefield which
operates 24 hours a day 7 days per week. Sainsburys is therefore able to raise and monitor
incidents by phone or via a customer-useable terminal at any time to ensure continued
operation of its business.
ICL currently uses and manages six service partners to ensure that Sainsburys receives the best
possible service available on each item of equipment.
ICL provides preventative maintenance for point of sale terminals, calculating the life span of
individual parts by monitoring their usage, and replacing the part before it fails. Systems
maintenance can therefore be planned and carried out at times to minimise disruption to the
store. ICL also provides additional services, such as valeting and electrical-safety testing to
help increase the life of individual parts.
In total ICL is responsible for the serviceability and maintenance of more than 9000 point of
sale terminals and 1500 petrol pumps spread across over 350 branches nationwide.
BUSINESS BENEFITS
* Sainsburys has fewer suppliers to deal with, reducing the effort required to manage the
contracts and resolve problems
* Provides a single point of contact, easing the support effort required to raise and monitor
problem incidents
* Sainsburys receives fewer invoices, reducing the effort required for their management
* Standardised service level information which allows easy management of the service
delivered
¢ Preventative maintenance resulted in improved service from the in-store equipment
* Choice of service levels, reducing unnecessary costs
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 27 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
it
ANNEX 6 - PATHWAY CASE STUDIES
6.15 CARDLINK (IRELAND)
CONTRACT AWARD : 1994
CLIENT : EASTERN HEALTH BOARD - THE IRISH TRIAL AWARDED TO
DELPHIC
TOTAL VALUE : N/A
CONTRACT ATTRIBUTES RELEVANT TO THE RESPONSE
* Provision of smart card technology to a government department
* Provision of smart card manufacture and personalisation services
* Provision of a migration path for smart card technology
* Provision of ongoing technical consultancy in smart card technology
* Provision of card print design and origination facilities
* Provision of card system development and design
* Conformance to international standards
© Demonstration of the inter-operability of the card with other systems
* Co-ordination with other project partners
CONTRACT TERMS
The project is fully funded by the Directorate General XIII of the European Commission and
forms part of a co-ordinated activity to research and extend the use of patient data cards in
Europe. The Irish trial of this EU-funded project is being run in co-operation with the Eastern
Health Board who issue smart cards to patients. DelPhic, the joint venture between De La
Rue and Philips, developed a card-based solution that could be used by general practitioners,
hospitals, pharmacists and patients, and provided smart card products and services to support
it.
BUSINESS OBJECTIVES
The CardLink project is a high-profile smart card project aimed at creating greater inter-
operability between Europe’s Healthcare systems. The project has the aim of using smart card
technology to improve the communication of medical information between general
practitioners, hospitals, and pharmacists no matter which member state they are in or language
they speak.
DESCRIPTION OF TASK
DelPhic is the prime contractor for the trial taking place in Ireland. It is required to work
with the Eastern Health Authority to provide the following services:
* System specification and design
* Technical consultancy and support
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 28 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
* Supply of smart cards and corresponding software
The smart card solution developed by DelPhic had to provide a link between patients, doctors,
hospitals and pharmacists. It also had to carry vital patient information in a code format
which could be understood by any member nation’s medical team, irrespective of their
nationality or linguistic ability.
It was essential that the card solution was highly reliable as it would be used in many life and
death situations by medical teams and there was no room for error or system failure.
DelPhic’s solution had therefore to meet the highest professional standards from a smart card
supplier.
To meet these demanding requirements, DelPhic’s card solution included the Philips TB100
3K byte EEPROM smart card incorporating a Motorola $C21 chip. DelPhic will also be
supplying the Irish trial with the necessary terminals, software, personalisation services and
the essential technical support to make the project components function collectively.
DelPhic’s sophisticated product solution and the flexible approach to developing the system
was made possible by its ability to supply an upgradable flow of high-tech products, services
and technical skills from its parent companies, De La Rue and Philips.
BUSINESS BENEFITS
* Use of a recognised market leader for the provision of smart card technology
* Access to the latest smart card and plastic card technology developments to enhance the
system
* A one-stop shop for all card system requirements; system design to card delivery and
ongoing technical consultancy
* Use of technical skills to design and implement a cost-effective and user-friendly solution
* Minimise the risk by using a high-security and stable supplier who is internationally
approved
¢ Investment in standardised technology
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 29 of 32
OJEC Notice 94/$ 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
6.16 DE LA RUE CARD TECHNOLOGY
MAGNETIC CARD PRODUCTION
De La Rue’s card making business is at the forefront of plastic card technology in the UK with
a market share in excess of 60%. The plastic card production site is one of the most advanced
and secure in Europe. It is an internationally approved supplier for Visa, MasterCard,
Europay, APACS, Groupement des Cartes Bancaires and conforms to the industry’s highest
security and audit procedures.
The services offered by De La Rue include :
* Card design - digital origination and various proofing options including plastic
* Hologram design and orientation
¢ Card manufacture - printing, lamination, application of signature panel and hologram
* Card personalisation - embossing, laser engraving, indent printing, thermal printing
¢ Card matching to a personalised carrier and insertion in an envelope
* Preparation of finished card for despatch via a secure transporter
¢ Production of PUN and secure despatch
* Production of PIN and secure despatch
De La Rue has the most extensive production facilities in Europe. Its existing production
capacities are approximately 70 million manufactured cards and 25 million personalised cards
per annum. The personalisation capacity is soon to be increased to 40 million per annum.
The following references demonstrate the range of De La Rue’s experience and expertise in
managing large-volume and complicated card production contracts whilst providing
guaranteed levels of service on a daily basis.
REFERENCE 1: MIDLAND BANK
The flexibility of De La Rue’s card production is exemplified by the Midland Bank contract.
This is the sole supply of 6 million cards and 3 million PUNs per annum.
In 1992, Midland Bank evaluated the opportunity for sourcing of all their card volume from
one supplier (previously it used three). The objectives were to achieve significant long-term
cost savings and improved service levels to their cardholders. De La Rue Card Technology
was awarded the contract which involved the production of a complex range of 40 card types,
24 carriers, 6 envelopes and many inserts.
Midland Bank agreed stringent performance and quality levels with De La Rue covering the
range of parallel production activities:
¢ Manufacturing and printing the base card to the highest industry standards
* Personalising the base cards and ensuring despatch within 24 hours of receipt of data
¢ Printing the PUNs for those cards going to branch
* Dealing with the complexities of multiple types of card, carrier, insert and envelope
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 30 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
* Despatching the cards to branches and customers by any one of 4 different despatch
methods
* At all times maintaining a 100% audit trail of production and despatch
REFERENCE 2 : THE AA
In 1994 the AA issued a tender for a 3-year contract for 18 million plastic cards to be
manufactured and personalised. This involved the issue of multiple types of card, carrier,
envelope and insert, resulting in a complicated mix of daily personalisation requirements.
De La Rue was successful in winning this contract because it could demonstrate its capabilities
in:
* Providing a complete and reliable end to end service
* Meeting the AA’s future requirements for new product development
* Extending theproduction capacity within the contract life
¢ Providing smart card technology
SMART CARD PRODUCTION
Through its partnership with Philips in smart card technology, De La Rue has the capability to
develop and deliver card-based payment products and turnkey payment solutions to a range of
applications which include; Banking, Healthcare, Pay TV, Telecoms, Mobile Communications,
Transport, National ID, Utilities, Electronic Purse.
The joint venture company DelPhic has been formed specifically to address the supply of
smart card technology to the UK and Irish markets, and has been involved in a number of
ground-breaking contracts and projects.
The DelPhic product and service portfolio spans three inter-related sectors which are
fundamental in providing a complete end-to-end service for smart card technology and
services.
1) Card Systems
« Smart card manufacture - microprocessor, memory and token memory card
* Smart card personalisation - pre-personalisation and customisation
2) Hardware and Software
* Stand alone readers
* PC-based readers
¢ Transaction terminals
¢ Introduction Kits
* Development Tools
* Personalisation tools
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 31 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 6 - PATHWAY CASE STUDIES
3) Systems and Support
* Strategic planning
* Consultancy
* System Design
* Business Case Analysis
* Project Management
¢ Training
DelPhic has also been selected by APACS (Association for the Payment and Clearing Services)
to define the functional requirement specification for the forthcoming smart card to be issued
by the UK’s Banks and Building Societies.
REFERENCE 3 : MONDEX PILOT IN SWINDON 1995
In July 1995 NatWest and Midland will pilot the Mondex smart card project in Swindon.
The project represents a global milestone in the use of smart card technology for person-to-
person transfer of electronic cash. It is unique in that it allows cardholders to :
1. Carry electronic cash on a card in the same way as it would carry real money in their
wallets.
2. Transfer electronic cash from their card to another cardholder’s card as if they were
actually giving them real money.
A key factor in winning this contract was DelPhic’s ability to satisfy all the development
requirements and meet a demanding production schedule, for example, for a dedicated
electrical and physical smart card personalisation service.
The Mondex Pilot also involves De La Rue Fortronic who has won the contract for the
development and supply of the dedicated Mondex terminal for the pilot.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 32 of 32
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 7 - CURRICULUM VITAE AND ROLE DESCRIPTIONS
7. CURRICULUM VITAE AND ROLE DESCRIPTIONS
This Annex contains the curriculum vitae and role descriptions for the Pathway
Management executive.
—
I Bid Team
JAJONES
I Director, / Director, Quality & I { Director Director I Director I Director
I Commercial & Finance I Risk Managemen: I I Business Development Technical Programmes I Operations
I AE OPPENHEIM I} MH BENNETT i SJ HODGKINS JCC DICKS MJBCOOMBS I SMROWE
L J i
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 7 - CURRICULUM VITAE AND ROLE DESCRIPTIONS
CURRICULUM VITAE
Name : John H. Bennett
Role : Managing Director, Pathway
Age: 50
Key Experience
1994-present Managing Director, Pathway
1993-1994 Director Marketing Support and Communications, ICL 65 staff and £8m
promotion budget. Responsible for corporate communication, brand
development, marketing services and international account development.
1989-1992 Sales and Marketing Director, ICL (UK) Ltd
150 marketing staff, 500 sales, £1 billion business. Responsible for all sales and
marketing policies.
1985-1988 Regional Director, Central Sales Region, ICL (UK)Ltd
550 staff, £165m revenue.
Career Summary
1994-1995 Managing Director, Pathway
1993-1994 Director Marketing Support and Communications, ICL
1989-1992 Sales and Marketing Director, ICL (UK) Ltd
1985-1988 Regional Director, Central Sales Region, ICL (UK) Ltd
1983-1985 Account Manager DHSS, Central Sales Region, ICL (UK) Ltd
1981-1983 Customer Service Regional Manager, ICL
1980-1981 Project Director Inland Revenue, ICL
Previous Career History
1977-1980 Regional Sales Manager, Civil Government, ICL
1975-1977 Regional Sales Manager, Transport, ICL
1973-1975 Area Sales Manager, Local Government
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 14
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
es <
ANNEX 7 - CURRICULUM VITAE AND ROLE DESCRIPTIONS
John H. Bennett, Managing Director, Pathway
Role
Direct Pathway’s business supported by the functions of Commerce and Finance, Business
Development, Risk Management, Technical, Programmes and Operations.
Responsibilities
* Grow Pathway’s relationship with BA/POCL
* Ensure the fulfilment of the main contract
* Establish strategic direction and vision supported by appropriate policy
* Identify and promote the culture and values of Pathway
¢ Provide leadership for Pathway and promote communication
* Ensure success of Pathway’s business plan
¢ Ensure and report the integrity of the business
¢ Ensure the provisions of the SQM are observed
* Own and manage SQM elements : Leadership, Policy and Strategy
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 14
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 7 - CURRICULUM VI
AND ROLE DESCRIPTIONS
CURRICULUM VITAE
Name: Anthony E. Oppenheim
Role: Director Commerce and Finance, Pathway
Age: 43
Key Experience
1991-1994 Manager, Strategic Business Initiatives, ICL
Focus on Mergers and Acquisitions, new business start-ups and disposals. Role
involved full project management from concept to live operation.
1988-1991 VP of Finance, ICL Retail Systems
Period of 100% growth, focus on the acquisition and integration, and the
development of the UK and US operations. Turnover increased from £150m per
annum to £300m per annum.
1986-1988 VP of Finance, ICL Inc., USA
Predominantly retail business in early phase of expansion. Turnover of £40m
per annum, now £150 million per annum.
1984-1986 Controller of Mainframes Systems
Mature business at a critical point of product transition for one generation to
another. Focus on commercial ‘smoothing’ and product introduction. Turnover
at transfer prices £250 million per annum.
Career Summary
1991-1994 Manager, Strategic Business Initiatives, ICL
1988-1991 VP of Finance, ICL Retail Systems
1986-1988 VP of Finance, ICL Inc., USA
1984-1986 Controller of Mainframes Systems
1981-1984 Controller of Scotland and North East Division, ICL
1981 Controller of Local Government and Public Corporations
Division, ICL
1978-1981 Manager, Profit Planning, ICL
Previous Career History
1976-1978 Manager, Product and Price analysis, Rank Xerox
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 14
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 7 - CURRICULUM VITAE AND ROLE DESCRIPTIONS
Anthony E. Oppenheim, Director Commerce and Finance, Pathway
Role
Manage all Commercial, Legal and Financial aspects of Pathway business in support of the
Managing Director and all Pathway functions.
Responsibilities
* Manage all commercial, financial and legal activities and the function’s resources
* Own and manage the BA/POCL contract and all associated subcontracts
* Ensure BA/POCL settle all accounts in accordance with contractual terms and conditions
« Ensure shareholders, subcontractors and staff are paid in accordance with agreements
¢ Ensure compliance with all applicable legislation
* Produce Pathway statutory accounts
* Produce Pathway’s five-year and one-year business plans and monitor performance against
these and the business case
* Analyse internal and external socio-economic trends of relevance to Pathway
* Own and manage functional subcontracts which are not related to BA/POCL
* Own and manage SQM elements : Resources, Business Results
* Manage Risk with regard to the Commerce and Finance function
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 14
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 7 - CURRICULUM VITAE AND ROLE DESCRIPTIONS
CURRICULUM VITAE
Name : Martyn H. Bennett
Role: Director, Quality and Risk Management, Pathway
Age: 43
Key Experience
1993-1995 Research and Development Manager, De La Rue PLC
20 staff and budget of £1 million. Establishment and management of a balance
of short-term, low-risk and longer-term, high-risk projects resulting in new
products and features, and the adoption of new manufacturing technologies.
Responsible for IS09001 new product development and introduction processes.
1990-1992 Senior Associate, Coopers & Lybrand Deloitte
Responsibility for generating business and managing and participating in
consultancy assignments. Involved in the development of technical strategy and
improvement of organisational effectiveness of major multinationals.
1988-1990 Division Technical Manager, 3M United Kingdom PLC
Technical responsibility for multi-million pound business, including resource
management, strategic planning, identifying business opportunities and liaison
with corporate product development organisations and key account senior
management.
1986-1988 Business Development Manager, Europe, 3M
Responsibility for establishing a new business in Europe, identifying and
developing market opportunities and distributing, communicating and co-
operating with US managers, developing joint development projects with
systems integrators and OEMs, and devolving European subsidiary involvement.
Career Summary
1993-1995 Research and Development Manager, De La Rue PLC
1990-1992 Senior Associate, Coopers & Lybrand Deloitte
1988-1990 Division Technical Manager, 3M United Kingdom PLC
1986-1988 Business Development Manager, Europe, 3M
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 14
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 7 - CURRICULUM VITAE AND ROLE DESCRIPTIONS
Previous Career History
1981-1986 Research Manager, Mars Confectionery, Mars UK Ltd
1979-1980 Senior Design Engineer, Transducers (CEL) Ltd
1977-1978 Senior Research Scientist, GEC Ltd
Martyn H. Bennett, Director, Quality & Risk Management, Pathway
Role
Manage Quality policy, assurance and processes which enable Pathway to exceed its service
expectations. To manage all risks that are a threat to the survival and well-being of Pathway.
Responsibilities
Quality
* Own Quality policy and manual
* Manage the development of Quality processes and procedures with the aim of gaining
1SO9001 accreditation
* Lead the development and maintenance of a culture of continuous Quality improvement
* Liaise with BA/POCL on Quality issues and performance standards. To liaise with all other
directors on Quality processes, procedures and performance that are in their areas of
responsibility
* Provide input to contract negotiations, agree Quality procedures and standards with
subcontractors
* Monitor, audit, input changes to Quality policy, processes and procedures; report regularly
on Pathway performance and status
Risk
* Own Risk Register
* Manage, control and gain resolution for all items on the risk register
¢ Liaise with BA/POCL on risks in their risk register. To liaise with all other directors on
risks that are in their areas of responsibility
* Provide input to contract negotiations for those risks which cannot be taken by Pathway
¢ Report regularly on the status of all risks
* Monitor and regularly audit and input change to the security policy of Pathway
* Ensure that adequate controls are included in the system, both computerised and
procedural, to ensure that all fraud is identified, reduced and ultimately eliminated
* Define the cardholder verification and card authentication methods to be used in the system
¢ Provide input to the system design for the processing of exceptions to ensure that Pathway
is not exposed to fraud in this area
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 14
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 7 - CURRICULUM VITAE AND ROLE DESCRIPTIONS
CURRICULUM VITAE
Name: Stephen J. Hodgkins
Role : Director, Business Development, Pathway
Age: 39
Key Experience
1993-present Managing Director’s Assistant, Girobank PLC, London
1991-1993 Head of Corporate Bank IT Developments and Projects, Girobank PLC,
London
Responsible for the interface between the Bank’s Information Technology
division and the Corporate Bank. Direct management of senior staff controlling
IT-related projects and developments, Corporate Bank projects and product
development strategy.
1990-1991 Key Accounts Manager, Girobank PLC, London
Responsible for managing and developing key bank customer relationships.
Career Summary
1993-present Managing Director’s Personal Assistant, Girobank PLC, London
1991-1993 Head of Corporate Bank IT Developments and Projects, Girobank PLC, London
1990-1991 Key Accounts Manager, Girobank PLC, London
1988-1990 Managing Director, The Taylor Group of Companies
1987-1988 Area Commercial Services Manager, Lloyds Bank PLC
1984-1986 Manager Leadenhall Street Branch, Lloyds Bank PLC
Previous Career History
1982-1984 Manager’s Deputy, Corporate Banking Division, Lloyds Bank PLC, Lombard
Street, London
1980-1982 Regional Personnel Manager’s Assistant
1975-1980 Various roles in branches of Lloyds Bank
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 7 of 14
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 7 - CURRICULUM VITAE AND ROLE DESC
TIONS
Stephen J. Hodgkins, Director, Business Development, Pathway
Role
Generate new business for POCL and Pathway by working with and through POCL.
Responsibilities
* Own and manage the Business Development function and its resources including the
development of Pathway’s own business development strategy
* Manage relationships with BA/POCL on behalf of the Business Development function
¢ Build and sustain understanding of BA/POCL’s marketplace
¢ Identify and orchestrate evaluation, impact assessment and prioritisation of new business
opportunities, to POCL’s and Pathway’s joint commercial benefit, comprising :
* New services to existing clients
¢ Existing services to new clients
* New services to new clients
* Develop joint and prioritised business plans for exploiting opportunities
¢ Through joint marketing and selling, implement the business plan
« In collaboration with the Director Commerce and Finance define service provision and
negotiate and win contracts, or hand over to a Bid Director designated by the Managing
Director
* Manage performance of subcontracts to the Business Development function, for example
promotion campaigns, market research and collateral development
* Own and manage SQM elements : Customer Satisfaction, Impact on Society
* Manage Risk with regard to the Business Development function
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 8 of 14
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 7 - CURRICULUM VITAE AND ROLE DESCRIPTIONS
CURRICULUM VITAE
Name : John C.C. Dicks
Role : Director Technical, Pathway
Age: 53
Key Experience
1993-present General Manager Enterprise Engineering
Responsible for the technology backbone of advanced or demanding products
and technologies which act as a differentiator for ICL in the systems integration
arena.
1988-1993 Director, Applications Product Group
Responsible for principal generic software applications. Built up ICL’s office
automation product from small beginnings to 3rd worldwide, by producing both
European and Asian versions. Produced the successful secure military version for
the Ministry of Defence (CHOTS) and was responsible for the cross-company
programme for the total military product during the period up to award of
contract.
Career Summary
1993-present General Manager Enterprise Engineering, ICL Enterprises
1988-1993 Director, Applications Product Group, ICL Midrange Systems
Division
1988 General Manager Communications and Integration Business,
ICL Office Systems
1985-1988 General Manager Open Systems Business Centre, ICL Network
Systems Division
1983-1985 Manager, Mainframes and Wide Area Networking, ICL Network
and Communications Division
1982-1983 Manager Networked Product Line Introduction, ICL Network and
Communications Division
Previous Career History
1975-1983 Project Management Roles, ICL
Including 5 years as project manager at the DHSS Newcastle/Washington
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 9 of 14
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 7 - CURRICULUM VITAE AND ROLE DESCRIPTIONS
John C.C.Dicks, Director Technical, Pathway
Role
Design, develop (or procure) and test solution architecture and its components, and hand over
to Programmes and Operations.
Responsibilities
¢ Own and manage the Technical function and its resources
* Manage relationships with BA/POCL on behalf of the Technical function
* Manage performance of contract and subcontract, let on behalf of the Technical function
and escalate as appropriate
¢ Authorise changes to technical architecture and resultant design
* Manage change control for changes to technical architecture and associated design
* Ensure technology refreshment is considered and its impact optimised in line with business
benefit
* Track and exploit new technology to the commercial advantage of Pathway and BA/POCL
* Undertake technical impact assessments on behalf of the Technical function and other
functions
* Undertake impact assessment, option evaluation, contract scheduling and other relevant
work in respect of proposed new business including activities in the 1995 Bid Process as
agreed
* Identify and implement best practice methodologies and tools in support of the Technical
function
¢ Secure and protect appropriate Quality accreditation, for example ‘Tickit’
* Manage Risk with regard to the Technical function
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 10 of 14
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ws he
ANNEX 7 - CURRICULUM VITAE AND ROLE DESCRIPTIONS
CURRICULUM VITAE
Name: Michael J.B. Coombs
Role : Director Programmes, Pathway
Age: 47
Key Experience
1994-present Bid Director, major procurements
Part of small team, establishing ICL’s strategy for responding to DSS’s ITSA
outsourcing procurement, CA’s NIRS2 replacement under PFI and the
BA/POCL PFI procurement.
1994 Director Business Applications, ICL
Responsible for establishing a business providing industry-specific software to
the Utilities and Logistics market place, as a result of a major reorganisation.
1992-1994 Manager, ICL Business Development Unit
Responsible for the change programme within ICL’s largest business division
that re-defined the medium-term business strategy and designed and set in place
a new organisation and core business processes to implement these strategies.
1992 Consultant - ITSA
Defining the position of ICL’s future products in ITSA’s technical architectures.
Career Summary
1994-present Bid Director, major procurements
1994 Manager, New Business Unit, ICL
1992-1994 Manager, ICL Business Development Unit
1992 Consultant - ITSA
1991-1992 Project Manager/Consultant British Gas Account, ICL
Previous Career History
1987-1991 Various Managerial Roles
1983-1987 Project Manager, Inland Revenue Computerisation Projects.
Cabling and computerisation of all Inland Revenue Offices.
Establishment of support mechanism for equipment and software.
Analysis of Inland Revenue business requirements, followed by software
development and management of joint applications development team.
Establishment of mechanism and strategy to allow technology refresh.
1969-1983 Various support and project management roles
Michael J.B. Coombs, Director Programmes, Pathway
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 11 of 14
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 7 - CURRICULUM VITAE AND ROLE DESCRIPTIONS
Role
Orchestrate the initial end-to-end programme delivery. Subsequently, on an as-needed basis,
orchestrate increments on that initial base.
Responsibilities
* Own and manage the initial build implementation
* Own and manage the Programmes function and its resources
* Define the Programme and its baseline
¢ Manage contract and subcontract performance with regard to the demonstration, pilot and
build phases of the initial implementation
¢ Prepare and maintain the programme plan
* Direct programme implementation through :
¢ Project and technical managers nominated from other functions in Pathway
¢ BA/POCL nominees
¢ Subcontractors owned by the Programmes function
* Monitor and control the sub-activities of the Programme to reflect its priorities
¢ Identify and implement best practice programme standards, methodologies and tools, and
associated project management counterparts
* Manage relationships with BA/POCL on behalf of the Programmes function
* Manage Risk with regard to the Programmes function
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 12 of 14
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 7 - CURRICULUM VITAE AND ROLE DESCRIPTIONS
CURRICULUM VITAE
Name: Stephen M. Rowe
Role : Director Operations, Pathway
Age: 45
Key Experience
1989-1994 POCL Improvement Programme Manager
Responsibility for managing a programme of service delivery improvement
initiatives 1993/1995. Leadership of action planning group (Girobank POCL) to
agree Service Delivery improvement project as part of partnership with POCL.
1993-1994 Benefit Agency Reconciliation Project Manager
Delivery of improvements to BA system to achieve full reconciliation between
the DSS books and their bank statements.
1991-1993 Benefit Agency Project Manager
Delivery of reconciliation and enquiry service for green girocheques.
Transferring the DSS system from Newcastle to Bootle and managing transition
for 100 million payments per annum.
Career Summary
1993-1994 Benefit Agency Reconciliation Project Manager
1989-1994 POCL Improvement Programme Manager
1991-1993 Benefit Agency Project Manager
1993 Head of Transmission Services
1991 Operational Control Manager
1989 Head of Reconciliation and Banking Services
1988 Postmasters Reconciliation Manager
1986 Clearing Operations Manager
Previous Career History
Various Managerial Roles :
Accounts Management
Personnel Policy
Management Accounts
Budgetary Control
Reconciliation and Settlement
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN
Page: 13 of 14
Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 7 - CURRICULUM VITAE AND ROLE DESCRIPTIONS
Stephen M. Rowe, Director Operations, Pathway
Role
Operate services in accordance with service level agreements (SLAs). The role includes :
On behalf of BA/POCL :
* Payment Management Service (PMS)
* Card Management Service (CMS)
* POCL Operational Support Services
* Help desks
¢ Counter support services
* Site services
¢ Training (ongoing)
* Management information (MIS)
On behalf of Pathway :
* Help desks
* Site services
¢ Training
* MIS
Responsibilities
* Own and manage the Operations function
* On behalf of Pathway take responsibility for Configuration and Asset Management
* Manage relationships with BA/POCL on behalf of the Operations function
* Manage contract and subcontract performance with regard to Pathway Operations
¢ Maintain the designated BA/POCL IT infrastructure in accordance with the technical
architecture and associated design authority
* Manage change control in respect of the Operations function
* Undertake work in respect of proposed new business including activities in the 1995 Bid
Process as agreed
* Identify and implement best-practice methodologies and tools in support of the Operations
function
* Secure and protect ISO9001 accreditation for Pathway provided services
* Own and manage SQM element : Processes
* Manage Risk with regard to the Operations function
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 14 of 14
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
S d
ANNEX 8 - RESEARCH PROGRAMMES
TABLE OF CONTENTS
8. RESEARCH PROGRAMMES ..
8.1 INTRODUCTION
8.2 DISCUSSIONS WITH VOLUNTARY ORGANISATIONS REPRESENTING LARGE
SECTIONS OF THE BENEFIT-RECIPIENT COMMUNITY .
8.2.1 INTRODUCTION .......ccseesseseeetetesseserenereeees
8.2.2 THE USE OF AGENTS TO COLLECT BENEFITS
8.2.4 IDENTIFICATION AND AUTHENTICATION ISSUE: .
8.2.5 USE OF ORDER BOOKS AS PROOF OF ENTITLEMENT TO CONCESSIONS.....c+cc0se00
8.2.6 RECOGNITION OF THE BENEFIT CARD BY CUSTOMERS WHO SUFFER VISUAL
IMPAIRMENT.
8.2.7 NEED FOR DETAILED ADVICE NOTE OF MONEY RECEIVED.
8.2.8 CONCLUSIONS
8.3 BENEFIT CARD....
RhWWNHERB BP
oacgqu
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ye
ANNEX 8 - RESEARCH PROGRAMMES
8.1
8.2.1
RESEARCH PROGRAMMES
INTRODUCTION
Acceptance of the benefit payment card and the new benefit payment system by
the customers is essential to the success of the overall service.
Pathway has undertaken two programs of research. Firstly to understand
customer views on the automation proposed and the general acceptability of the
card (see 8.3), and secondly to identify through representative bodies, the
concerns of special needs groups within the customer community (see 8.2).
These concerns raise some issues that can be addressed wholly by Pathway and
others that will need to be considered by us in conjunction with the Contracting
Authorities to ensure that what is asked for by the interested organisations,
although technically possible, is allowable or affordable within the current
payment rules.
DISCUSSIONS WITH VOLUNTARY ORGANISATIONS
REPRESENTING LARGE SECTIONS OF THE BENEFIT-
RECIPIENT COMMUNITY
INTRODUCTION
As mentioned at several points in this response, Pathway recognised at an early
state the importance of understanding the requirements of the new benefit
payment system from the point of view of the customers. If the new system is
to be implemented quickly and easily there must be a very high degree of user
acceptance right from the beginning. This means that the Service Provider must
first understand what happens in general on the customer side of the post office
counter and second, the exception conditions that have to be catered for to meet
the requirements of particular groups.
This is reinforced by the duty placed on the Service Provider to manage the
customer education campaign that will accompany the launch of the new
system, and the public relations aspects of the changeover throughout the roll-
out period.
Pathway does not assume that customers will simply accept the new system
because the Government says they must. Any scheme that is insensitive to
customers’ personal concerns can be expected to run into user resistance, which
could be very difficult to overcome.
Pathway therefore believes that it is essential, in its own interests as well as those
of the Contracting Authorities and customers, to have a benefit card scheme that
is as sensitive as possible to the underlying concerns of potential users of the
card and satisfies their requirements.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 6
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 8 - RESEARCH PROGRAMMES
To gain insight into the sensitivities and concerns of customers, Pathway has
requested, and received, briefings from a number of organisations which
represent major groups within the customer community. These are :
ACRE - Action with Communities in Rural England
Age Concern
Carers National Association
MENCAP - The Royal Society for Mentally Handicapped Children and
Adults
NACAB - The National Association of Citizens Advice Bureaux
RNIB - Royal National Institute for the Blind
SENSE - The National Deafblind and Rubella Association
All of these organisations have been helpful and have presented to us their views
of the requirements of their particular constituency concerning the payment of
benefits.
ACRE and NACAB focused on the requirements of customers living away from
the main towns and depending mainly on a probably rural sub-post office for
the collection of their benefit. The other organisations provided us with insight
into the requirements of particular groups within the customer community.
8.2.2 THE USE OF AGENTS TO COLLECT BENEFITS
All of the above organisations have concerns in the area of customers who are
unable to go to the post office in person to collect their benefit. We believe that
Pathway’s proposals for the authorisation of agents on either a temporary or
permanent basis goes a long way to addressing and satisfying these concerns.
However, there is a strong requirement for the continuing use of casual agents,
for example, where an old person has a sudden bout of illness which requires
the use of a casual agent for just a week or two. This matter will need to be
resolved in conjunction with the representative organisations and perhaps could
be met by an insistence that people nominate an agent at the same time they
complete the other arrangements for the receipt of their pension. An additional
approach would be to ensure that all local authority home helps are
automatically issued with a benefit card which would identify them if they are
suddenly called upon to collect benefit for one of their clients.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 6
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ie
ANNEX 8 - RESEARCH PROGRAMMES
8.2.3
8.2.4
PART PAYMENTS
A requirement has been expressed to allow a customer to collect only part of the
money which is due to them. An example would be a pensioner who has been
on holiday and on returning home does not wish to leave the post office with
several weeks’ entitlement on their person. This is considered a personal safety
risk,
Within the current proposals, it will be possible for individuals in receipt of
more than one benefit payment, to collect a particular payment and leave the
balance on the system. However, the whole of a single benefit payment must be
taken in its entirety and there is no provision for part payment of a single
benefit payment.
IDENTIFICATION AND AUTHENTICATION ISSUES
As a result of our discussions we believe that Pathway’s proposals to initiate the
benefit card system using a magnetic stripe card with signature identification is
the approach that will command the most widespread acceptance in the shortest
time.
We have found real opposition to the use of photocards for very understandable
reasons (although research among a group of individual customers gave
photocards their support - see Section 4.4.6.4). People who are in some way
disabled or disfigured feel extremely uncomfortable and uneasy about the use of
their photo on any publicly available or frequently used document, while
understanding that it may be necessary to have photographic records on securely
held, confidential files. MENCAP made the additional point that many sufferers
of Downs Syndrome tend to look alike so photographs are not very useful as
unique identifiers,
Older people, also, do not wish to be reminded of their declining appearance
and their attitudes seem to correspond, in many respects, to those of the
disabled.
Although we have not yet had an opportunity to speak to any of the
organisations concerned with the homeless we image that their concerns would
be very similar.
On balance, therefore, Pathway has concluded that identification through
signature is the approach most acceptable to customers and one which they will
willing accept from the outset.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 6
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 8 - RESEARCH PROGRAMM!
The RNIB have advised us that this need not constitute an obstacle for blind or
partially sighted people. Many visually handicapped persons are now provided
with signature templates which allow them to sign their signature for official
purposes. The banks provide them as part of their support to their customers
suffering from visual impairment and the RNIB itself can produce them in its
own facilities. On the advice currently available therefore the signature
approach should be satisfactory.
There are still issues to be resolved regarding the authentication of customers
who are illiterate and Pathway will have proposals for this in due course.
USE OF ORDER BOOKS AS PROOF OF ENTITLEMENT TO CONCESSIONS
Among the elderly and disabled, whose benefit is paid through the supply of an
order book, there is real concern as to how the new system will continue to
provide them with evidence of their status.
Currently the order book states the nature of the benefit they are receiving and
this constitutes satisfactory proof of entitlement to the providers of a wider
range of concessions.
The approach currently envisaged of issuing all benefit cards in a single livery,
which does not indicate the type of benefit to which the holder is entitled, will
no longer indicate to the provider of the concession that the cardholder is, in
fact, entitled to that concession.
The option of using the letter of confirmation of benefit which is issued at the
time a customer comes onto a particular benefit is not considered feasible
because of the length of time a person may remain on benefit without another
letter being issued. The potential problems cited range from letters getting
easily lost or misplaced through to getting dog-eared by constant use or being
always carried in a handbag.
There was a further concern about using the notification of benefit letter
regarding confidentiality. Because the letter shows the amount of money the
person has been awarded as well as the reason the person is obtaining benefit,
there will be a great deal of sensitivity in showing this letter to third parties as
proof of entitlement. This information is regarded as both confidential and
sensitive and, in our view, rules out the notification letter as an acceptable
solution to this issue.
Pathway will continue to work on this issue and, in particular, give
consideration to making cards available in different liveries for different
benefits.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 6
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 8 - RESEARCH PROGRAMMES
8.2.6
8.2.7
RECOGNITION OF THE BENEFIT CARD BY CUSTOMERS WHO SUFFER
VISUAL IMPAIRMENT
Blind and partially sighted people may need some additional feature on the card
to help them recognise that this card is their benefit card. It has been suggested
to use that this could be done by, for example, embossing the words ‘Benefit
Card’ or a suitable logo onto the card in either braille or ordinary roman
characters. There may be other approached to enable easy tactile identification
of the benefit card and Pathway will examine these in due course.
NEED FOR DETAILED ADVICE NOTE OF MONEY RECEIVED
Several organisations mentioned the need for benefit recipients to be provided
with some form of printed statement confirming how much money they had just
been paid and, if this comprised more than one benefit, how the total payment
was made up.
This is part of a wider debate about how people are going to be able to keep
track of whether they are up-to-date with their benefits collection or not.
People who are becoming forgetful value their order book because they have a
physical object that tells them exactly where they are up to and the date when
the next payment is due. The post office stamp on the counterfoil also serves as
a visible reassurance that they have collected everything to which they are
entitled. With the withdrawal of order books this visible reassurance will
disappear and with it, it is suggested, much of the peace of mind that it has
delivered, particularly to older people.
These needs has been partly addressed in the Pathway response, which proposes
that every counter position will be equipped with a printer that will produce a
detailed Advice Note. This will state the name of each benefit being paid, the
amount of money paid out against it, and the total amount paid.
However, this does not fulfil the other functions of the order book referred to
above and Pathway will wish to continue discussions about this with the
Contracting Authorities and the relevant voluntary organisations during the
demonstration phase.
CONCLUSIONS
The above list of concerns is not exhaustive. However, it serves to indicate the
range of issues that will need to be resolved, in conjunction with the main
representative organisations, to ensure that the changeover achieves maximum
acceptability within the customer community.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 6
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ei
ANNEX 8 - RESEARCH PROGRAMMES
We have found the representative organisations to be well-informed about the
proposed changes and anxious to help Pathway understand the requirements of
the people they represent. They have volunteered to continue to support
Pathway through the demonstration phase and to take part in any trials that may
be run to test the feasibility of the solutions being proposed. They will also be
willing, when the time comes, to use their publications to help explain the
changeover and what it means to their particular customer group and to do so in
language which their group will understand.
We will be continuing this program of consultation over the next few weeks and
will report any further significant findings to the Contracting Authorities.
8.3 BENEFIT CARD
Qualitative Research - Summary of Findings
Please see the attached report which has been prepared by McCann-Erickson on
behalf of Pathway.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 6
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 9 - TECHNOL!
TABLEOF CONTENTS
9. TECHNOLOGY TRENDS
9.1 FRAUD REDUCTION
9.1.41 INTRODUCTION .
9.1.2 PLASTIC CARD FRAUD .
9.1.3 CARDHOLDER VERIFICATI
9.1.4 COUNTERFEIT AND FORGERY..
9.2 CARD TECHNOLOGY (MAGNETIC STRIPE VS SMART)
9.2.1 INTRODUCTION . seeeeneneeee
9.2.2 MAGNETIC STRIPI
9.2.3 SMART CARD TECHNOLOGY
9.2.4 CONCLUSION.......
9.3 THE MIGRATION PATI
9.3.1 INTRODUCTION ....
9.3.2 PATHWAY'S MIGRATION OPTIONS .
9.3.3 DESCRIPTION OF THE CARD MIGRATION OPTIONS .
9.3.4 SUMMARY OF THE MIGRATION OPTIONS FOR ALL CARD SPECS .
9.4 PATHWAY’S PROPOSED MIGRATION STRATEGY ...
9.4.1 INTRODUCTION ..
9.4.2 THE REASONS BEHIND THIS "APPROAC!
9.4.3 PATHWAY'S MIGRATION OPTIONS FOR HOLOGRAMS.
RBOwWRE PE
oaua»gdahowon
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 9 - TECHNOLOGY TRENDS
9. TECHNOLOGY TRENDS
This annex covers :
¢ Fraud Reduction
* Card Technology (Magnetic Stripe vs Smart)
* Card Migration Path
* Pathway’s Proposed Migration Strategy
9.1 FRAUD REDUCTION
9.4.4 INTRODUCTION
This section begins by putting plastic-card fraud into perspective, and then
moves on to discuss the issues that will be relevant in Pathway’s delivery of a
fraud-reduction programme to BA/POCL.
9.1.2 PLASTIC CARD FRAUD
With the advantage of hindsight it is clear that plastic card fraud peaked in
1991-92. The political and commercial concerns that resulted from the record
card fraud levels of those years led to a series of initiatives among issuers which
have proved successful. Figures released by APACS (Association of Payment
Clearing Services) show that since those peak years there has been a reduction of
fraud of nearly 40% and the number of instances are forecast to decline further.
This demonstrates the success of the initiatives being driven by APACS in co-
ordination with the UK Banks and Building Societies.
Pathway, via Girobank’s Fraud Risk Management department is at the forefront
of all industry developments for fraud control and is a key member of all senior
fraud bodies, where it has a major influence in developing fraud policy and
strategy.
The main factors in combating fraud are the increasing levels of authorisation
together with the lower (or zero) limits being imposed on many merchants. The
number of authorisations in 1994 was less than 30% . This is set to rise to
approximately 50% by 1996. Increasing on-line authorisation to combat fraud
has been possible only because the UK acquirers were able to reach more
favourable agreements on the telecommunication costs of providing on-line
authorisations.
Other initiatives to help reduce fraud levels have been endorsed by Pathway’s
shareholder De La Rue, who are the UK’s only card maker to put laser-engraved
photographs and signatures onto financial payment cards such as those used by
the Royal Bank of Scotland and the National 8& Provincial Building Society.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 1 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
Although this highly secure anti-fraud technology was recommended by Home
Office White Paper 26 on Cheque and Card Fraud, it is generally not considered
to be a complete solution because it fails to address the issue of ATM fraud.
The trend that is proving most alarming for the UK’s card issuers is the rise in
plastic card counterfeiting. In 1987 counterfeit fraud was negligible but by
1993 it had increased almost ten times, despite fraud-prevention initiatives. It is
clear therefore that existing technology will not combat counterfeiting.
Such belief is already evident among the UK Banks who, along in the rest of
Europe, are now preparing to embrace smart card technology. This technology
is viewed as a means of defeating the fraudsters and counterfeiters and at the
same time delivering new value-added services to customers.
If the French card industry is any guide to the anti-fraud effectiveness of smart
card technology, it will eliminate presently known forms of fraud almost
entirely. In 1986 the rate of domestic fraud was 0.27%. Today with 100% of
the French 22 million cards converted to smart cards, the rate of domestic fraud
has reduced to 0.04%.
Pathway recognises that two classes of fraud will exist within the benefit
payments system : customer fraud and encashment fraud. The Procurement
Service Boundary requires that Pathway take on responsibility for reducing
encashment fraud. Pathway’s fraud-reduction strategy is committed to placing
as many obstacles as possible in the way of fraudsters attempting to carry out
unauthorised payments.
Pathway also acknowledges that no security strategy can be absolute and that it
is always possible to conceive new ways of circumventing protection. However,
as explained in Pathway’s Proposed Migration Strategy (see sub-section 3 in
Annex 9), our approach to combating fraud is enhanced by the ability to
introduce evermore sophisticated techniques in order to stay ahead of the
fraudster. With each card issue and re-issue, new and improved security features
can be implemented seamlessly. In this way we will significantly increase the
time, effort, and level of sophistication required for potential compromise of
card system security and, as the cost to the fraudster increases, opportunities for
fraud are greatly reduced.
Pathway’s fraud reduction strategy addresses two main areas of exposure within
encashment fraud : cardholder verification, and counterfeit or forged IOPs.
Pathway’s strategy for reducing encashment fraud has two principle thrusts :
(a) To provide BA/POCL with more sophisticated means of verifying the
identity of the cardholders at the point of encashment.
(b) To provide BA/POCL with options for a long-term, secure, machine-
readable technology that protects the integrity of the machine-readable data
on the IOP.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 2 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 9 - TECHNOLOGY TRENDS
9.1.3
9.1.3.1
CARDHOLDER VERIFICATION
Cardholder verification refers to the process of identifying the cardholder as the
genuine owner of the card. Verification can be achieved in a number of ways.
The Cardholder Verification Methods (CVMs) available will depend on the type
of card used, the environment in which the card is to be used, reliability factors
of the verification process and public acceptance.
In this section we assess each possible CVM together with its availability and
applicability to the Benefit Agency.
PERSONAL IDENTIFICATION NUMBER (PIN)
The use of PINs is widespread and has proved a relatively effective way to verify
the identity of a cardholders. Two environments exist for using PINs : firstly, at
unattended terminals such as Automated Teller Machines (ATMs) that are
commonly found outside high-street banks; secondly, at attended devices such
as the point of sale (POS) in a supermarket. Using the PIN to verify the
cardholder’s identify is particularly common outside of the UK, particularly in
France.
The use of the PIN at the point of encashment would require additional
equipment and the use of encryption and authentication algorithms to keep the
PIN secure. In the UK, PINs are generally considered acceptable for ATM
usage, however their use at the point of encashment could meet with
considerable resistance. Another cause for concern is that, if benefit payment
relies on the use of a PIN and this use is ever compromised, it is possible that
the entire service network could also become compromised.
With respect to special user groups, results published by Market Opinion
Research Group (MORI) in 1992 suggested that the 55+ age group were least
likely to have their PIN number compromised as they were less likely to write it
down or store it with their card. MORI’s conclusions suggested that the
tendency for cardholders to write down a PIN number increases with age up to
middle age, but that the 55+ age group appear to be the most cautious of all.
The 55+ age group were also less likely to store their PIN with their card than
cardholders from the 15-24 age group.
Pathway recognises that the use of a PIN to verify the identity of the cardholder
at the point of encashment would be unsuitable for a high proportion of the user
groups within the 25 million customer population. Also the use of PINs to
verify the cardholder’s identity has its own shortcomings as it can act as a
‘transferable ID’.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 3 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 9 - TECHNOLOGY TRENDS
9.1.3.2
9.1.3.3
BIOMETRICS
Probably the only true way to identify an individual is via a biometric. In the
past the reliability of systems for reading biometric features proved to be
commercially unacceptable. Likewise, retinal and vein geometry scanning have
also proved socially unacceptable cardholder verification techniques.
The great advantage to BA/POCL of biometric cardholder verification
techniques is their reliance on the non-transferable aspects of a customer’s
identity. They would also remove the discretionary element of verifying identity
by checking a visible signature.
The disadvantage comes from the difficulties associated with the enrolment
process (in other words, obtaining the customer’s biometric feature). There will
inevitably be customer resistance to whatever biometric is selected.
The unanimous view of the industry is that the only viable platform for the
introduction of a biometric is to store data on a smart card. The smart card
would allow storage of a customer’s biometric feature (fingerprint, photo or
signature) in a machine-readable form. The data could be compressed and
stored in a secure area on the smart card chip.
This would mean some additional equipment at the point of encashment,
however the ability to verify cardholder identity off-line as well as on-line offers
a distinct security advantage to benefit encashment.
Pathway is confident that biometric data stored securely on a smart card
provides a more sophisticated means of cardholder verification, however, that
the technology should be aimed at users who will not be resistant to using (or
enrolling for) the technology.
PHOTOCARDS
In recent years a small number of banks and building societies have used laser-
engraved photographs on cards as a means of cardholder verification. These
cards have successfully lowered fraud at the point of sale where the identity of
the cardholder can be easily checked against the supporting photograph. The
Home Office White Paper 26 on Cheque and Card Fraud recommended that :
* Financial payment cards be laser-engraved with photographs
* Laser-engraving technology be used, because it is the only photocard
technology that is sufficiently secure
Despite this recommendation, the banks and the police think that using a
photograph as a cardholder verification technique would simply cause the
fraudsters to adjust their current practices and that levels would soon return to
current levels.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 4 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 9 - TECHNOLOGY TRENDS
9.1.3.4
SIGNATURES
Signatures are the most common CVM in use today. They are socially
acceptable but also carry the most exposure to counterfeit. There are, however,
many different ways that signatures can be captured, stored and used.
The most common method of storing signatures is on the signature panel on the
back of a magnetic stripe card. This method has the benefit of being easy to use
and visible to check, but is prone to fraud because there can be no control to
ensure that the signature is checked by the cashier.
The next most common method is to laser-engrave the signature into the card.
This provides a durable signature and prevents the signature from being
tampered with without showing evidence of tampering. Laser-engraving
equipment is not available to the market and is only sold to selected security
print firms. De La Rue is the only laser engraver in the UK. For this reason
banks and other users of laser-engraved cards feel confident that De La Rue’s
products are protected from fraud (by individuals and by organised crime).
Pathway has ranked the signature types in order of their increasing resistance to
fraud. (Please also refer to the card samples displayed at the end of Annex 9.)
* Magnetic stripe card with hot stamp panel (See Specimen 1)
* Magnetic stripe card with paper signature panel (See Specimen 2)
* Magnetic stripe card with paper signature panel plus indent printing (See
Specimen 3)
* Magnetic stripe card with laser-engraved signature (See Specimen 4)
(Resistance to fraud : Specimen 1 < Specimen 2 < Specimen 3 < Specimen 4)
Another method is to store the signature as a two-dimensional bar code on the
card. The benefit of this is that only the reader displays the signature, making it
harder to forge but leaving the final check with the cashier. There are, however,
no accepted standards in this area yet.
A signature can be stored more securely on a smart card. In this case the
signature is displayed or printed when the smart card is read but again, to make
this technology effective the cashier must have controls in place for checking
that the signature offered matches the one displayed. The smart card option
would also offer the benefit of allowing BA/POCL to verify the cardholder
identity in off-line mode.
Please refer to the Smart Specimen 1 : DS card sample at the end of Annex 9. It
is equally possible to check the signature (without it being on the card) by
sending the signature from a central database. There still remains the element of
human fallibility of the cashier checking/not checking the signature.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 5 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
Si do:
ANNEX 9 - TECHNOLOGY TRENDS
9.1.3.5
9.1.4
Digitised signature techniques are also available. These techniques rely on use
of a smart card and on the fact that each person’s signature is unique in that the
pressure on the paper, the time taken and the gaps between initial or names are
unique to each individual. Whilst this technique has the advantage that it is a
piece of equipment and not a person who checks the signature, we all vary our
signatures slightly over time, making it impossible to reject every false signature
and accept every correct signature. The problems of false acceptance and false
rejection have never been completely solved and therefore this technique is used
only in access-control systems.
CONCLUSION
Pathway confirms that the signature strip on a magnetic card with a visible
signature will be used for the majority of cardholder verifications. Additional
verification procedures will be provided for the benefit payment system to cater
for suspicious circumstances. These will be based on information already held
by BA and known by the valid customer, such as date of birth, amount cashed
last week, post office where benefit was last cashed, and so on.
Pathway recognises that these processes, together with the overall counter
operation, represent a significant change to current counter procedures.
Pathway confirms that we will develop and jointly agree the new counter
procedures through consultation. From these new procedures we will jointly
develop an operational framework which clearly defines the responsibilities and
associated risks that Pathway and BA/POCL must accept.
Pathway stresses that an important contribution to cardholder verification is the
correct issue of cards, The card management system must recognise that the
overall card issue process includes card production, card distribution, card
collection and card activation. Each of these is a separate step and there must be
a clear separation between, in particular, card distribution to the post office and
card collection by the customer. CMS will ensure that card activation only
occurs after the card has been collected by the customer.
COUNTERFEIT AND FORGERY
The current paper-based order books and girocheques provide a major
opportunity for fraud through counterfeit (reproduction of the whole
document) and forgery (alteration of parts of the document to enable fraudulent
gain).
Traditional security features to counter these threats include :
* Specialist paper and watermarks
* Inks that are difficult to copy or that react to bright light or solvents
¢ Printing techniques such as latent image
* Chequer-board pattern
¢ Asymmetrical numbering
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 6 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
cv Wcated
ANNEX 9 - TECHNOLOGY TRENDS
* Optically variable inks
* Holograms
All of these techniques are in use in many sections of the financial community
and could be used to produce a secure form of the current order book.
A magnetic stripe card IOP will be subject to similar risks of counterfeit and
forgery as financial payment cards because of the way in which cards can be
reproduced by criminals. Pathway will use its holographic capabilities to reduce
such instances of card-based IOP counterfeit.
Our holographic capabilities will be provided by the De La Rue company, De La
Rue Holographics. A more detailed description of De La Rue Holographics and
the proposed holographic feature of our proposal is given in The Migration Path
at the end of this Annex. Pathway view the hologram as a valuable security
feature on the card for the following reasons :
(a) The hologram’s diffractive structures produce optically variable colour
shifts, image switches, and depth and movement effects that are highly
recognisable and characteristic. These effects are generated by the
mechanism of optical diffraction, which cannot be simulated by any print
technique.
(b) The hologram’s structure is a transparent micro-structure overlaid on a
metal reflector of scale size. It cannot be copied by colour copier, laser
scanner or any other print or reprographic technique.
(c) The origination and production of embossed holograms is technically
complex and requires considerable specialist knowledge and investment.
(d) The use of an attractive hologram on a card produces an eye-catching and
attractive image with definite optical changes and colour switches. This
encourages a high level of public awareness and recognition of the card.
Holograms were initially introduced to payment cards to prevent changes to the
embossed characteristics on genuine cards (in particular the last four digits of the
account number). The device has proved to be successful because alterations
(usually carried out using a heat process) damage the foil and distort the
hologram.
Pathway recognises the following four types of counterfeit threat to the
holographic security of their proposed card types :
(a) Simulation by the use of diffraction foils. This is the lowest level of
imitation and is often an obvious counterfeit.
(b) Holographic contact by copying or re-mastering. This is still an inferior
form of production and is easily noticeable.
(c) Mechanical copying of the relief surface pattern. This is possible but the
resultant hologram is usually significantly degraded.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 7 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 9 - TECHNOLOGY TRENDS
9.1.4.1
9.2
9.2.1
(d) True holographic re-origination. This is the most severe potential threat to
holographic security. With the growth in the holographic industry across
the globe, the necessary skills to create holograms are more widely available.
There is a growing number of originating factories that emboss with
relatively low capabilities.
In the past counterfeiters did not use holographic technology because they could
use only available materials and inks. These included plain foils, in time
migrating to diffraction grating foils. More recently holographically produced
holograms have been used which have been manufactured by technically
competent professionals from the holographic industry.
CONCLUSION
The evolution of counterfeiting has been mainly directed at plastic card
counterfeiting and Pathway recognises the fact that serious counterfeiters will be
receiving expert advice and technical assistance. To minimise this threat,
Pathway’s holographic capabilities will be able to provide BA/POCL with a
migration path of secure holographic features. This migration path is explained
at the end of this Annex. The only reliable way to defeat counterfeiters is to
migrate IOPs to smart card products. To date there are no recorded cases of a
functional smart card being successfully counterfeited.
In order to minimise the risk of fraud on the card, Pathway agree with BA’s view
that the card should have no intrinsic value. Pathway anticipates that the card
will hold only the card number or NINO number, a card issue number and the
customer name. Altering or reproducing these details would serve no purpose
because there would be a discrepancy between the card details and card
information associated with payment details.
If a duplicate card is presented, the post office clerk has additional information
(date of birth, nominated post office, and so on) to verify identity. The design
of the Benefit Payment Service will ensure that a payment can only be collected
once, and that all other attempts will be considered potentially fraudulent.
CARD TECHNOLOGY (MAGNETIC STRIPE VS SMART)
INTRODUCTION
This section starts by looking at magnetic strip card technology and then
describes smart card technology in detail. The section explains some of the
issues surrounding these technologies (such as the standards) before concluding
with an explanation of the card technology for Pathway’s strategy.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 8 of 24
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 9 - TECHNOLOGY TRENDS
9.2.2.1
9.2.2.2
MAGNETIC STRIPE TECHNOLOGY
INTRODUCTION
Magnetic stripe technology has matured to an extent where most people now
use it in one form or another. It is a simple, reliable, and widely understood
technology which was never intended to provide a secure system.
The technology is so well understood that the criminal fraternity are only too
aware of the components and the magnetic media used in banking systems and
infrastructures.
Pathway acknowledges that the main catalysts in the search for alternative
solutions are the technological limitations of the magnetic stripe, the increase in
fraud and counterfeit levels, and the need for enhanced card-authentication
mechanisms.
However, it would be foolish to dismiss magnetic stripe technology as
redundant and outdated. Its reliability as a robust, dependable technology has
been proven over the last twenty five years, although it is only in the last five
years that the magnetic stripe on plastic cards has been used to its full extent.
Increased use of electronic POS terminals means that the magnetic stripe is used
for its data capture (rather than its embossing) features.
ADVANTAGES FOR THE BA/POCL
Magnetic stripe card technology is a proven technology which has the benefit of
having been used extensively over 25 years in many different applications and in
many different environments.
The reliability, durability and flexibility of the technology has been endorsed by
all major card issuers in the world, who have recognised its usefulness by fully
integrating it into their card payment infrastructures.
In addition to its use as a standardised payment media for global payment
systems, there is also the benefit of it being a well-understood technology with
the experience and knowledge of an industry behind it to support, enhance and
deliver technical development. Materials as well as expertise are readily
available from manufacturers and suppliers at prices that are inexpensive in
comparison to smart cards.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 9 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
A
ef t
ANNEX 9 - TECHNOLOGY TRENDS
9.2.2.3
9.2.3
9.2.3.1
DISADVANTAGES FOR THE BA /POCL
Magnetic stripes were never designed to be a secure media. As a result,
traditional payment cards have always had a low resistance to counterfeit and
fraudulent attack. The nature of the magnetic media means that it does not
provide a secure means of data storage. A fraudster can easily copy the data
from a genuine payment card onto another blank card quite easily; this is
knowing as ‘skimming the magnetics’.
In addition, the data on magnetic stripe cards can often become corrupted or
erased by exposure to household objects that are surrounded by magnetic fields,
such as fridge magnets, television sets or even the magnet on a lady’s handbag
fastener. Many cardholders will inadvertently damage their cards by exposing
them to strong magnetic fields from household items.
The magnetic stripe has also the disadvantage of having a limited data storage
capacity which cannot be increased. The storage space will become the limiting
factor in the delivery of new services using magnetic stripe cards.
Finally, unlike smart cards, the magnetic stripe on a payment card can be read
only and cannot be written to once it is issued to the cardholder. Issuing new
payment parameters for a cardholders can only be achieved by re-issuing a new
card, rather than letting the system’s software write directly to the card the next
time it is used.
SMART CARD TECHNOLOGY
INTRODUCTION
The smart card is basically the result of combining a plastic card with a silicon
chip microcircuit. The silicon chip microcircuit is embedded into a cavity on the
plastic card which is then covered by a gold contact plate known as the ‘stamp’.
The silicon and the microcircuit are fixed in the base of the cavity by a resin and
are connected by electrical wires to the stamp. The stamp provides electrical
connection to the microcircuit and also seals the entire diameter of the card’s
cavity so that there is a smooth and seamless join with the plastic card.
The smart card is not a new technology. The first patents were filed (in Japan
only) in 1970 by Kunitaka Arimura, however it was the French journalist
Roland Moreno who is more widely accredited with inventing the smart card.
He filed the first worldwide patents in 1974, covering the concept of embedding
a microcontroller into a regular bank-style plastic card. Moreno’s concepts
promoted discussion within the French Government, Finance, Public
Transportation, Medical and Telecommunications sectors to an extent where a
series of technology trials soon followed.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 10 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 9 - TECHNOLO!
TRENDS
9.2.3.2 THE SMART CARD MARKET
Since those early pioneering days, a vast industry has grown up across the world
representing significant investment. The smart card market in Europe is still
developing and is reckoned to be growing at a rate of 45% per annum. It is
recognised that the major period of growth is still to come.
Europe’s smart card market is far more mature and technically advanced,
compared with the other world regions. Europe is also setting the pace in smart
applications development and smart card expertise. Today’s smart card
technology in Europe is being used successfully in numerous applications,
including banking, medicine, transport, health, pay TV, Payphone, Utilities and
mobile communications.
In spite of the wide international appeal and consumer acceptance of the smart
card technology, it is fair to say that the smart card industry, from a global
perspective, has barely begun to realise its full potential. Many experts use the
analogy that the smart card is in the same stage of evolution today as the
personal computer was back in 1983.
9.2.3.3 CLARIFYING PATHWAY’S DEFINITION OF A SMART CARD
Before going further, it is worth clarifying Pathway’s use of the term ‘smart card’
in this proposal. Pathway uses this term to refer to a card that has on-board
intelligence and the processing capability to interpret the data it receives (in
other words, a card with a microprocessor).
The following smart card products proposed by Pathway conform to the above
definition :
* DS smart card (See Specimen 1)
* TB100 Multi-Application card (See Specimen 2)
A more complete description of these smart cards is given in the following
section entitled The Migration Path. Please note that Pathway’s definition of a
smart card does not apply to memory cards. Memory cards have the capability
to respond to different inputs but cannot manipulate data because there is no
microprocessor present. The media often wrongly label these cards as being
smart, but in fact they are more suited to being called ‘dumb cards’.
9.2.3.4 EXPLAINING SMART CARD FUNCTIONALITY
The basic components of a smart card are the following four element connected
together :
* Data Memory
¢ Program Memory
* Microprocessor
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 11 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
9.2.3.5
The Data Memory allows important data storage while the Program Memory
and the Microprocessor allow the data processing facilities. These components
make the smart card a more sophisticated IOP, capable of secure data storage
and data processing facilities.
At the time of encashment the advanced functionality of this IOP will provide
greater security to the entire encashment processes. The smart card is capable of
the following functions :
¢ Authentication of the card as being a genuine IOP
* Verification of the cardholder’s identity
* Certification that the transaction has actually taken place.
* Codification of the transaction data on the transmission lines
The various possible security enhancements and the increased functionality give
smart card technology-based IOPs a distinct advantage over the more passive,
insecure magnetic stripe IOPs. The measure of this advantage can be viewed
against the three following criteria, identified within the text of the SSR
¢ Fraud and risk management
* New applications
* The provision of value added services
Pathway’s card technology proposals will be capable of providing the BA/POCL
with a common, upgradable and flexible solution to meet these and future
criteria.
ADVANTAGES FOR BA/POCL
The use of smart cards for benefit encashment would significantly reduce the
opportunities for fraud/counterfeit activities. With each re-issue of a smart card,
Pathway will be able to introduce new features to enhance smart card security,
to stay one step ahead of the fraudster. To date, no recorded cases of
counterfeit of a functional smart card have been registered with Interpol.
Apart from providing a Card Authentication Method (CAM) which is vastly
more secure and reliable than that of a magnetic stripe card, the smart card
CAM can also be configured to work in on-line as well as off-line mode.
The smart card also provides the ideal technology platform to introduce a
biometric for the Cardholder Verification Method (CVM). The biometric
stored in a secret area of the smart card could be a unique cardholder identifier
such as a photograph, fingerprint or signature. The secure storage’ of this
feature would provide the smart card with the distinct advantage of being able
to carry out a CVM check in off-line mode.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 12 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 9 - TECHNOLOGY TRENDS
9.2.3.6
9.2.3.7
The cost effectiveness of using smart cards cannot, however, be justified by the
reduction of fraud and lower network costs. The migration to a more dynamic
IOP such as a smart card will provide a flexible, and adaptable technology
solution to introduce and deliver new services and applications. This is due to
the sophisticated functionality and data storage and processing capabilities of the
card,
Finally there is also the additional benefit of knowing that smart card
technology is future-safe and that Pathway can provide a common, flexible and
upgradable solution in compliance with the latest international smart card
standards. Providing common upgradable and flexible solutions to benefit
encashment in compliance with international standards is core to Pathway’s
migration strategy.
Standards exist for smart cards in payment systems due to the 1994 Eurocard,
MasterCard and Visa (EMV) Joint Specification. Details of this and the
background to the question of standards is provided in Section 9.2.3.7.
DISADVANTAGES FOR BA/POCL
To move directly to a smart card format for day one would require a higher
initial investment from BA/POCL and this would be difficult to justify. The cost
of a smart card is still significantly higher than a magnetic stripe card. However,
the smart card is infinitely more adaptable than the magnetic stripe card so the
cost-effectiveness of service delivery must be considered against that of unit cost.
Likewise the use of smart cards will only be appropriate for certain user groups
as there is the issue of customer acceptance of the IOP. The issuing of a smart
card that relies on a biometric CVM to work in off-line mode would require the
customer to be firstly, capable of submitting their biometric for card issue
purposes and secondly, be ready to accept the procedure for carrying out the
CVM.
THE KEY ISSUE OF STANDARDS
Today it is assumed that magnetic stripe cards from the different payment
systems and card associations can be accepted at the same terminal. This
compatibility did not happen by coincidence. It is the result of close co-
operation amongst the major network providers to establish global standards
and specifications for magnetic stripe card technology
The last few years has seen unavailability of global standards as a barrier to the
further development of the smart card industry (and the inter-operability of
smart cards in global payment systems).
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 13 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 9 - TECHNOLOGY TRENDS
9.2.4
In 1994, recognising the importance of smart card technology to the future of
the plastic card payment systems, Europay, MasterCard and Visa joined forces
to issue a joint specification for smart cards in payment systems. The result of
this co-operation was the development of a common standard that provides a
uniform platform to support global inter-operability.
This EMV Joint Specification exists and paves the way for the universal use of
smart cards in payment systems. This will not only provide a major catalyst for
the smart card industry in general, but will allow Pathway to offer BA/POCL,
with confidence, a flexible and upgradable migration pathway to smart card
technology.
CONCLUSION
Pathway’s solution will provide the best balance between the following four
factors that impact the decision on proposing card technologies :
« Economic : what is the best ratio for card cost versus security
* Effectiveness : the requirement to deliver benefit payments effectively
* Availability : the same IOP procedure must be available to all post office
locations
* Reliability : the service must be reliable and upgradable
Pathway believes that magnetic stripe technology has an important role to play
in the migration of IOPs from paper to plastic card format. We also believe that
magnetic stripe technology will co-exist successfully alongside smart technology
for benefit encashments for the foreseeable future. However it is only the
inherent security, flexibility and adaptability of smart card technology that will
provide BA/POCL with the necessary technological platform to combat long-
term fraud, reduce costs and support the introduction of new products and
services.
Pathway recognises the problems of collecting accurate signatures and/or
photographs of reference and also that without these procedures the
introduction of plastic smart cards would be delayed by up to a year.
Pathway do not believe that there is significant and lasting cost/benefit
advantage from day one which would justify using smart cards for all customers.
Pathway’s strategy for day one proposes magnetic stripe cards together with the
necessary cardholder verification and card authentication processes.
Pathway also recognises that the use of smart card technology will be
BA/POCL’s best long-term product delivery solution.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 14 of 24
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 9 - TECHNOLO!
TRENDS
9.3
9.3.1
9.3.2
9.3.3
THE MIGRATION PATH
INTRODUCTION
This section looks first at the various magnetic stripe and smart card products
that Pathway can deliver in the migration path. Second, it explains the Pathway
card migration strategy for day one and post day one. Finally, it describes how
Pathway’s overall migration strategy is enhanced by the use of its holographic
capability and details some of the holographic options available.
PATHWAY’S MIGRATION OPTIONS
The card migration options available to Pathway are summarised as follows :
a) Magnetic Stripe Card Options
* Magnetic stripe card with hot stamp panel (See Specimen 1)
* Magnetic stripe card with paper signature panel (See Specimen 2)
* Magnetic stripe card with paper signature panel plus indent printing (See
Specimen 3)
* Magnetic stripe card with laser-engraved signature (See Specimen 4)
b) Smart Card Options
* DS smart card (See Specimen 1)
¢ TB100 Multi-Application card (See Specimen 2)
Note : All the migration options listed above are card types that are
already being produced on an industrial scale for European card markets.
All the card types are available through De La Rue, who is a principal
shareholder in Pathway.
The card types listed above come with a security hologram designed and
manufactured by De La Rue. A description of Pathway’s holographic
capability is also provided in this section.
DESCRIPTION OF THE CARD MIGRATION OPTIONS
This section provides a description of the card migration options and refers to
the card samples displayed at the end of this Annex. It also highlights the
additional card features, security and functionality that position the card on
Pathway’s proposed migration path.
Pathway recognises that a card’s functionality and security can only be
significantly increased once there is a migration to smart card technology.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 15 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
9.3.3.1
Pathway would also like to emphasise that the extent of the smart card
migration is not limited to the smart card options described in this response.
BA/POCL will benefit from Pathway’s extensive smart card development skills
and technical resources throughout the life of this contract. BA/POCL should
not underestimate Pathway’s capability to provide new smart card solutions and
products during this contract. However for this first response Pathway has
proposed two smart card options which are suitable as logical extensions to the
card migration path.
MAGNETIC STRIPE CARD OPTIONS
Specimen 1 : Magnetic stripe card with hot-stamp panel
This card has a hot-stamp signature panel for the customer’s signature. The hot-
stamp panel provides the first of three signature panel options that will support
the CVM method of visibly checking the customer’s signature. This white panel
is easily applied at manufacture but is the class of panel most likely to be
compromised by a fraudster (changing the existing signature; overlaying the
panel with a new one; removing the panel and replacing it with a new panel).
This panel does not offer a significant security barrier against counterfeiters who
will be able to reproduce it.
Pathway foresee no significant production problems in supplying card Specimen
1 with this hot stamp panel feature for mass issue on day one. Pathway’s
strategy does not recommend that card Specimen 1 be used in the migration
from paper IOPs to magnetic stripe card IOPs
Specimen 2 : Magnetic stripe card with paper signature panel
This card uses a more secure signature panel for the customer’s signature. This
tamper-evident paper panel provides the card with a more effective barrier for
countering most attempts by fraudsters to remove an existing signature on the
panel. The security inks used in the design of the panel discolour if there are
any attempts to remove it using a solvent or water. This type of tamper-evident
paper panel is a sensitive security material which is designed and manufactured
by De La Rue.
Pathway foresees no significant production problems in supplying card
Specimen 2 with this paper panel feature for mass issue on day one. Pathway’s
strategy does not recommend that card Specimen 2 be used in the migration
from paper IOPs to magnetic stripe card IOPs.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 16 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 9 - TECHNOLOGY NDS
Specimen 3 : Magnetic stripe card with paper signature panel plus indent
printing
This card uses the same tamper-evident security paper panel described in card
Specimen 2. The only difference is that the security of the card is further
enhanced by the inclusion of indent printing along the top of the panel. Indent
printing on the panel offers a more sophisticated security barrier against
counterfeit and fraudulent attack than is possible with Specimen 2. The indent
printing feature is applied at the personalisation stage of the production process.
Pathway foresees no significant production problems in supplying card
Specimen 3 with indent printing on the paper panel for mass issue on day one.
Pathway believe that card Specimen 3 contains the best card cost/security ratio
for magnetic stripe cards, and that it is the most appropriate card for issue on
day one.
Specimen 4 : Magnetic stripe card with a Laser-engraved Signature
This card type represents the most significant barrier to counterfeit and
fraudulent attack. The signature in this example (‘Jennifer Auden’) has been
laser-engraved into the core of the card below the surface laminate. To be more
precise, the laser-engraved signature has been formed by burning a series of dots
into the card’s core. The dots on the core are protected by the surface laminate
layer, which means that the signature is securely isolated within the card and
cannot be scratched or touched without irrevocably damaging the card.
The signature is applied at the personalisation stage. Customers would receive
their card with their signature already laser-engraved securely on the card. This
method would counter fraud on intercepted cards such as card Specs 1, 2, and 3,
which are distributed with virgin signature panels which are open to fraudulent
attack. Likewise any efforts to remove or alter the signature would easily show
that the card has been tampered with.
Despite the fact that laser engraving is recommended by the Home Office and
that De La Rue already uses this technology as part of its personalisation process
for UK banks and building societies, Pathway do not believe it is an appropriate
card type for mass issue on day one. The reason is that the laser engraving of
signatures requires customer signatures to be collected, batched under a suitable
enrolment scheme, and then transmitted in digitised form to De La Rue for laser
engraving. Pathway believes that there would be logistical problems in the
collection of 25 million signatures over the roll-out period, and despite the
high-security benefit card Specimen 4 being a migration option, it would be
better suited to post day one
Pathway’s migration strategy recommends that card Specimen 4 could be :
* Directed at paper IOPs for high risk customer groups
¢ Phased in for magnetic stripe card renewals of card Specimen 3
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 17 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 9 - -HNOLOGY TRENDS
9.3.3.2
¢ Directed at customer groups who are fraud risks but do not justify the cost or
functionality of a smart card
SMART CARD OPTIONS
The migration to a smart card based IOP would bring distinct advantages over
magnetic stripe or paper IOPs. These advantages have been identified in Section
4 of this response and throughout the previous two sections of Annex 9.
Before examining the two proposed smart card options of Specimens 1 and 2 in
more detail, it is worth clarifying Pathway’s migration strategy for smart cards.
Pathway’s strategy does not recommend smart cards for day one
Pathway does not believe it is an appropriate card type for mass issue on day
one, and that the migration from paper IOPs for day one should be limited to
magnetic stripe cards.
Pathway believes that smart cards have a major role to play in the migration
from paper or magnetic stripe card IOPs, but that they are not appropriate for
day-one issue. Pathway’s migration strategy has smart cards positioned as a
post-day-one card type which will be introduced to more defined customer
groups where there is sufficient justification for its use instead of a magnetic
stripe card.
Pathway believes that : the relatively higher cost/security ratio of this card; the
anticipated levels of ‘techno-fear’ from customers; and the logistics of collecting
and supplying customer data/biometrics in a suitable format will prevent the
issue of this card type on day one. Pathway consider smart card Specimen 1 and
2 to be equally inappropriate.
Specimen 1: DS smart card : Microprocessor card
The DS card has been positioned on the Pathway migration path because of its
flexibility, security and relative inexpense. The DS card is the same smart card
type used by the French banks for its 22 million cardholders.
The DS card is designed around a simple operating system together with a
sophisticated memory architecture. Both these features make the DS card a
perfect card type when the BA/POCL require IOPs with a more powerful and
secure storage capability,
This card type can be easily adapted to implement a range of new applications
because the file structure of its memory is based on 1 K byte of EEPROM
architecture that allows for easy information updating and single-voltage supply.
In terms of security, certificate generation is based on the DES algorithm which
provides dynamic card authentication and certifying file contents after memory
writing or updating,
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 18 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 9 - TECHNOLOGY TRENDS
9.3.4
The DS card can be described as a general-purpose, multi-service microprocessor
card whose compatibility with international standards permits Pathway to
provide BA/POCL with the benefits of a guaranteed smart card migration
capability. It also provides the compatibility to interchange with other smart
applications that become integrated with POCL’s services.
Specimen 2 : TB100 ;Multi-application card.
The TB100 card has been positioned on the Pathway migration path because of
its more advanced and sophisticated functionality. This card has the capability
to cater for a wide range of new services and applications that require the
inherent security of multi-application smart cards.
The card’s hierarchical organisation of data files will allow BA/POCL to
introduce various independent applications onto the card without compromising
the security of each application.
The card’s security architecture ensures the independence of each application on
the card and that they are protected against tampering. This feature would
therefore allow BA/POCL to share the card’s memory resource with other third-
party issuers without compromising the respective security levels and
functionality of the individual applications on the card.
The advanced functionality and sophistication of the TB100 will permit
Pathway to provide BA/POCL with the benefits of a guaranteed smart card
migration capability that is future-safe. Compliant with international standards,
it is a smart card that can accommodate new and existing applications from
BA/POCL as well as those from a third parties.
SUMMARY OF THE MIGRATION OPTIONS FOR ALL CARD SPECS
CARD TECHNOLOGY AVAILABLE FOR DAY ONE
Magnetic Stripe Cards
* Magnetic stripe card with hot stamp panel (See Specimen 1)
* Magnetic stripe card with paper signature panel (See Specimen 2)
* Magnetic stripe card with paper signature panel plus indent printing (See
Specimen 3)
CARD TECHNOLOGY AVAILABLE POST DAY ONE
Magnetic Stripe Card
* Magnetic stripe card with laser-engraved signature (See Specimen 4)
Smart Card
© DS smart card (See Specimen 1)
* TB100 Multi-application card (See Specimen 2)
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 19 of 24
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
9.4
9.4.4
9.4.1.1
Note : All card Specs are available with hologram migration options.
Pathway’s description of these holographic options are described
at the end of the Annex.
PATHWAY’S PROPOSED MIGRATION STRATEGY
INTRODUCTION
Pathway’s strategy is committed to the continued introduction of evermore
sophisticated techniques to stay one step of the fraudster.
At each stage of the migration path, Pathway will provide BA/POCL with a fully
flexible, upgradable card-based payment system that incorporates a range of
technology options.
Pathway’s migration path to new fraud-resistant technologies will ensure that
the best and most cost-effective methods of delivery of benefit encashment and
the delivery of new services, will always be available, at the right time and at the
right price.
Pathway recognises that the move from a paper and/or magnetic stripe IOP to a
smart card IOP will provide a means to upgrade the entire security of the benefit
encashment systems. The cost of this migration cannot be justified on fraud
alone but on the added functionality that smart cards can provide. Despite the
initial investment cost for BA/POCL, this added functionality can be delivered
more cost-effectively than any other proposed IOP format.
Pathway also recognises that if BA/POCL are to realise the business
opportunities and service benefits arising from the migration path then they will
have to align themselves with a service provider capable of delivering a seamless
and managed migration path within desired time constraints.
DAY ONE APPROACH
From the three options available on day one, Pathway recommends that
BA/POCL choose card Specimen 3 as the first plastic card format to be used as
an IOP.
Magnetic stripe card with paper signature panel and indent printing (See
Specimen 3)
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 20 of 24
OJEC Notice 94/5 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 9 - TECHNOLOGY TRENDS
9.4.1.2 POST DAY ONE APPROACH
For post-day-one Pathway recommends using the following card Specimens :
Magnetic Stripe Card
Magnetic stripe card with laser-engraved signature (See Specimen 4)
AND/OR
Smart Card
¢ DS smart card (See Specimen 1)
* TB100 Multi-application card (See Specimen 2)
9.4.2 THE REASONS BEHIND THIS APPROACH
9.4.2.1 INTRODUCTION
Despite the limitations of magnetic card technology, Pathway is proposing its
use for day one as the best and most cost-effective method to deliver benefit
encashments, as well as the best and most cost-effective method for both CVM
and CAM processes.
a) Resistance to Fraud and Counterfeit
In terms of fraud and counterfeit resistance, Pathway’s migration strategy is
based on the resistance of the card to fraud and counterfeit attack. The rankings
of the various Specs are given below :
Low Resistance to Fraud and Counterfeit
MS Specimen 1 < MS Specimen 2 < MS Specimen 3 < MS Specimen 4 <
Smart Specimen 1< Smart Specimen 2
b) Functionality to Deliver New Services and Applications
Pathway believes that smart card technology is not applicable for mass issue on
day one. Pathway’s smart card options will comprise the sophisticated
functionality and security architecture of the latest smart card technology. The
card options proposed by Pathway for post day one are ranked below :
Card Functionality and Security Architecture :
Smart Specimen 2>Smart Specimen 1> MS Specimen 1, 2, 3 and 4
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 21 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 9 - TECHNOLOGY TRENDS
c) Card Per Unit Cost versus Cost Effectiveness
In terms of per-unit-cost of a card, it is clear that a magnetic stripe card will be
less expensive than a smart card for the foreseeable future. As described above,
Pathway’s migration strategy is committed to providing BA/POCL with the best
and most cost-effective methods for delivering benefit encashment and new
services. Pathway has stated in this proposal that the introduction of a card-
based IOP cannot be justified only on the basis of the IOP’s ability to reduce
fraud and network costs, but on its ability to support the delivery of new
services and applications.
Pathway recognises that the per-unit-cost of a card is not the major criteria in
the selection of a card type, but rather the cost-effectiveness of the card in the
context of a service delivery mechanism. Below are two sets of rankings which
indicate the relative per-unit-costs of the card options and secondly, the relative
cost-effectiveness of cards to deliver new services and applications.
Low Per Unit Cost :
MS Specimen 1 < MS Specimen 2 < MS Specimen 3 < MS Specimen 4 <
Smart Specimen 1 < Smart Specimen 2
Magnetic card Specimen 3 is magnetic stripe card with a paper-signature panel
and indent printing was chosen to maximise the benefits of using a high-security
paper-signature panel which is further enhanced (during the personalisation
process) with indent printing. Specimen 3 is considered by Pathway the best
and most cost-effective method for day one, given the constraints identified of
laser-engraved or smart card technology on day one for mass issue.
Cost Effectiveness for Delivery of New Services and Applications
Smart Specimen 2> Smart Specimen 1> MS Specimen 1,2,3,4
Pathway recognises that their strategy focuses on magnetic stripe cards for day
one, but are aware that the use of smart cards will provide BA/POCL’s best long-
term product delivery solution.
Note : Examples of all the card specimens referenced are given at the end of
Annex 9.
9.4.3 PATHWAY’S MIGRATION OPTIONS FOR HOLOGRAMS
9.4.3.1. INTRODUCTION
Pathway is able to provide additional migration options for its proposed
hologram features during the migration path. These features and references to
card samples are explained below, after a short explanation of our holographic
capability.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 22 of 24
OJEC Notice 94/S 165-58937/EN. Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 9 - TECHNOLOGY TRENDS
The holograms will be designed, manufactured and supplied by De La Rue
Holographics (DLRH), which is a wholly owned subsidiary of the De La Rue
ple.
DLRH is a leading producer of holograms for credit, debit, charge and
identification cards in Europe, the Far East and South America, and is the sole
supplier of holograms for the Irish social welfare card. DLRH conforms to all
the security regulations and procedures laid down by the UK’s inspection body
for the UK Banks (APACS). DLRH is also IS09001-approved and is a founder
member of the International Hologram Manufacturers Association (IHMA).
9.4.3.2 HOLOGRAPHIC OPTIONS
Each hologram generated by DLRH for Pathway’s cards can incorporate an
original and exclusive design created as a unique stamp of quality and
authentication. The technology combines state-of-the-art laser optics with
conventional printing and converting methods to provide three distinct levels of
holographic security.
9.4.3.2.1 First Level Security
This comprises classical holographic features, incorporating image switches and
parallax. These effects are typified by holograms of simple 3D models and
2D/3D rainbow-embossed holograms using planes of art positioned at various
depths, The active element is a transparent microstructure overlaid on an ultra-
thin metal reflector, which cannot be simulated by colour copier, laser scanner
or a reprographic technique.
9.4.3.2.2 Second Level of Security
A second level of security is incorporated using more specialist visual features.
DLRH have created an extensive portfolio of these security features, which
require complex optical equipment and knowledge even for a well-equipped
laboratory to re-originate combinations of these features and provide a
considerable increase in security whilst maintaining a brightness and clarity
essential to public recognition.
These combinations features include :
¢ Progressive Colour Features
¢ Exact Register Features
¢ Dual Channel Features
* Multiplex Images
* Stereograms
* Kinetic Diffractive Features (see hologram Specimen A)
* Computer Generated Artwork
* 3D Models
* Moire Pattern Features (see hologram Specimen A)
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 23 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 9 - TECHNOLOGY TRENDS
9.4.3.3 PATHWAY’S APPROACH
Pathway has submitted two hologram samples with this response. These can be
found alongside the card samples given at the end of this Annex. Pathway has
included two types of hologram samples for this response :
¢ Hologram Specimen A : ‘Lion’ (Metallic)
* Hologram Specimen B : ‘Ships and Anchors’ (Hot Foil HRI)
This is only a suggestion and new development and origination of suitable
designs can be produced to meet the BA/POCL’s approval.
Pathway’s approach is to use Hologram Specimen A : Lion
The metallised ‘Lion’ image includes two high security features :
9.4.3.3.1 I Moire Pattern Features :
This technique has been developed to record onto a holographic image patterns
of light and dark Moire fringes. This enables a virtually unique pattern to be
formed which would be very difficult to copy.
9.4.3.3.2 Kinetic Diffractive Features
This feature uses sets of surface diffraction gratings designed to produce
particular movement features such as rotations and oscillations on tilting. This
technology can be combined with conventional 2D/3D holography.
Hologram Specimen B : ‘Ships and Anchors’
This hologram when foil blocked onto a suitable substrate produces a hologram
with image replay and colour shift similar to the fully metallised material yet
allowing data below the hologram image to be clearly visible. It also includes a
kinetic diffractive colour shift previously described.
Hologram Specimen B uses a High Refractive Index (HRI) which refers to the
physical nature of the layer covering the hologram profile. The microstructure
is coated with an ultra-thin film of a glassy inorganic compound which has a
high refractive index. The overall effect offers subtle security with obvious
advantages for the integration over printed photographs or data.
Pathway Response to COMMERCIAL IN-CONFIDENCE Page: 24 of 24
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
FUJ00098232
FUJ00098232
FUJ00098232
FUJ00098232
ANNEX 10 - GLOSSARY OF TERMS
GLOSSARY OF TERMS
Pathway Response to COMMERCIAL IN-CONFIDENCE
OJEC Notice 94/S 165-58937/EN Date: 08/06/95
ANNEX 10 - GLOSSARY OF TERMS
This term :
Has this meaning in this document :
ACC
A DSS Area Computer Centre. There are four of these around
the UK
ACD
Automatic Call Distribution
ACT
Automated Credit Transfer. This refers to an automated
method of paying benefits directly into bank accounts, It is
used particularly in the case of disabled claimants
Agency
An abbreviation for Executive Agency, which is a semi-
independent public body reporting to a Government minister,
such as the Benefit Agency
Agent
BA usage : person appointed by the customer to act on his or
her behalf, and to receive and deal on his or her behalf with
any sums payable to him or her
POCL usage : person in charge of any post office except a
directly managed office (post offices owned and staffed by
POCL)
ALPS
Automated London Post office System : hardware and PC-
based ESNS software (an existing ICL-POCL contract
currently rolling out within the M25 motorway)
APACS
Association of Payment Clearing Services
API
Application Program Interface
APT
Automated Payments Terminal. It is used to facilitate bill
payments in post offices and it uses smart cards
ATM
Automated Teller Machine
Attribute grammar
Riposte’s technique for storing data. Riposte stores the
description of the data item and its associated value in a data
file
Authentication
This is part three of the payment authorisation process that
allows the post office clerk to make a benefit payment
The process is :
Identification/Verification/Authentication/Authorisation
Authentication is the process that determines whether the card
or foil is valid (in other words, not forged). This is done
partly by inspection and partly by checking the validity of data
held on the card, such as the issue number
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE Page: 1 of 9
Date: 08/06/95
FUJ00098232
FUJ00098232
cy
ANNEX 10 - GLOSSARY OF TERMS
This term :
Has this meaning in this document :
Authorisation
This is the final part of the payment authorisation process that
allows the post office clerk to make a benefit payment
The process is :
Identification/Verification/Authentication/Authorisation
Authorisation is largely an automatic process, assuming all
other parts of the process have been passed. It consists of
checking that the payment is being made at the right place and
the right time. For example, whether the allowed number of
foreign encashments has been exceeded
Beneficiary
The person awarded a benefit payment by the DSS (in other
words, a DSS customer)
Benefit system
Refers to both the computerised and the clerical benefit
systems
Best-of-breed
Best industry practice or best product of its type currently
available
BPS Benefit Payment Service
CAD Computer Aided Design
CAM Card Authentication Method. The method by which the card
is judged to be valid - either a chip or the card number on the
card
CAN Card Activation Number. This refers to a 4-digit code
allocated during card production. It is printed on the pick up
notice and also held on the system and it is used only once, to
activate the card
CBT Computer Based Training
CEN Comité Européen pour Normalisation
Change Management
Refers to a process of managing changes that are related to
specifications, baselines or contracts during the provision of
the Pathway service
CIN Card Issue Number
Claimant A person who has claimed a benefit payment from the DSS (in
other words, a DSS customer)
Client An organisation that uses POCL as their shop
window/counter/service point (such as Girobank, DNS, BBC,
DVLA, BT)
CML A division within BT
CMOS Complementary Metal Oxide Semiconductor
Commercial Management
Contract Management
Communications
workstation
A workstation (normally one per LAN) that manages
communications with a particular correspondence server
Contracting Authorities
The DSS and POCL
Correspondence server
A component of Riposte which links to post offices through a
wide area network to distribute payment information and
capture transaction details
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE Page: 2 of 9
Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 10 - GLOSSARY OF TERMS
This term :
Has this meaning in this document :
CounterAction
An Post counter automation project
Counter environment
Encompasses the room and the ergonomics of the room where
the counter staff sit
Counter infrastructure
Encompasses the H/W, S/W and peripherals used by the
counter staff
Counter interface
Encompasses the visible face of the software, the data capture,
the general human-factor engineering of the countertop and
the interaction of the counter staff with customers
Counter Interface Service
The service provided by the Service Provider that supports
counter clerks in providing counter services. The service
boundary for this is expected to be between the service
provided by the Service Provider and counter clerks
CRC Cyclic Redundancy Check
CRISP. A stand-alone EPOS system used in Post Shops
CRU Counters Remitting Unit. In other words, a very big post
office
Cryptography Technique for scrambling data (derived from the Greek for
‘hidden writing’)
CSF Critical Success Factor
Customer BA usage : person who has applied for or claims benefit, or
his agent or appointee
I POCL usage : person coming into a post office to transact
business
CVM Cardholder Verification Method. Method by which the
cardholder is judged to be valid. Methods include PIN,
biometrics, photocard and signature
D2D Design to Distribution - an ICL system-build facility located in
Ashton
DBFO Design, Build, Finance and Operate
DDE Dynamic Data Exchange
Demonstrator phase
Initial proving activity of the pilot programme which occurs
during Stage 3 Contract Negotiation/Pilot Commencement
DES Data Encryption Standard. A US-defined algorithm
Desktop A component of Riposte which supports the transaction
development environment that gives access to interface
controls and provides for rapid application prototyping
Digital signature The electronic equivalent of a written signature
DLRH De La Rue Holographics, part of the De La Rue Group
DSK Digital Signature Key
DVLA Dept of Transport Driver and Vehicle Licensing Agency
EBT Electronic Benefit Transfer _
ECCO+ A POCL back-office accounting system that produces cash
accounting and client summaries
EEPROM Electronically Erasable Programmable Read Only Memory
EFQM European Foundation for Quality Management
EFT Electronic Fund Transfer
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE Page: 3 of 9
Date: 08/06/95
FUJ00098232
FUJ00098232
i
ANNEX 10 - GLOSSARY OF TERMS
This term : Has this meaning in this document :
EMV alliance Europay/MasterCard/Visa alliance. This alliance has jointly
specified standards for smart cards
Encashment Receipt of cash by a customer for an authorised payment,
using the desired instrument of payment
End-to-end Stretching from the instruction to pay to the completion of
the counter transaction, it includes payment, other POCL
services provided and also the delivery of reconciliation and
management information to both the DSS & POCL
Enquiry Request for information about transaction records, from a
client to POCL, Also requests from the DSS to paper storage
sites for sight of a foil/cheque (later a receipt) to verify
possible fraudulent encashment
EPOS Electronic Point of Sale
ESNS Electronic Stop Notice System. This is software (rolled out on
the ALPS platform) that provides electronic notification to
post offices of lost, stolen or recalled IOPs
Fall-back arrangements
Plan B, for when plan A does not work. Recommended
actions to be taken to overcome circumstances of failure
FDDI I Fibre Distributed Digital Interface. This refers to a physical
. network
FM Facilities Management
Foreign encashment
Encashment made at a post office in the UK other than the
‘nominated post office’
FTE Full-Time Equivalent
HCI Human Computer Interface
HRI High Refractive Index
Identification
This is the first part of the payment authorisation process that
allows the post office clerk to make a benefit payment
The process is :
Identification/Verification/Authentication/Authorisation
This term is applied to the identification of the cardholder to
the system. It will identify the benefit entitlement and
personal details of the cardholder by using the card number to
retrieve the information from various Pathway systems
IHMA
International Hologram Manufacturers’ Association
TIN
Industry Identification Number. This refers to the first 4 digits
of the card number of a credit card. It identifies the type of
credit card (for example, VISA or MasterCard)
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE Page: 4 of 9
Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 10 - GLOSSARY OF TERMS
This term :
Has this meaning in this document :
Indent printing
Refers to plastic card personalisation. It is the indenting of
characters into the body of the card with a transfer foil to
colour the characters (e.g. black). Unlike embossing, it does
not indent through to the other side of the card to produce a
raised feature. The primary account number will be indent
printed into the paper signature panel
Instrument of payment
(IOP)
Examples are a girocheque, a family allowance book (foil) and
acard
Investing in People
ICL’s Investing in People process was used as the role model
for the DTI-sponsored Investors in People scheme
Investors in People
A Government-backed scheme for setting training standards
IPR
Intellectual Property Rights
ISDN
Integrated Services Digital Network
Journal message
A Riposte transaction formatted as a single text string which
Riposte replicates to a journal message store
Journal server
A component of Riposte which manages the journaling, data
distribution and replication functions at a local post office
Journal server workgroup
Riposte workstations on the same LAN
Journaling
The recording of transaction details and system events, such as
logon, logoff, add/modify/delete user and password
management
LAN Local Area Network
Live trial A limited trial in a live environment which occurs during the
Operational trial phase
Magnetic swipe card
A plastic card with embedded magnetic stripe containing
tracks of data. Widely used with PINs in personal financial
applications
Mails
A set of applications used in Ireland by An Post for postal
services
Management of Change
Management of Change manages the process of cultural
change from an enterprise view. In the context of the current
BA/POCL procurement, it refers to the cultural effects on BA,
_POCL, the customers (general public) and Pathway
MICR Magnetic Ink Character Recognition
MNS A division within British Telecom
MOP Method of Payment. For example either an IOP or ACT
MORI Market Opinion Research Group
MSR Magnetic Swipe Reader
NAO National Audit Office
NFSP. National Federation of Sub-Postmasters
Nominated post office
A post office selected by the customer to be the one at which
he/she will normally encash payments
[OCR
Optical Character Recognition
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE
Page: 5 of 9
Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 10 - GLOSSARY OF TERMS
This term :
Has this meaning in this document :
OPENframework
This is the method created by ICL for undertaking systems
integration in an open systems world. OPENframework is
equipped to engineer solutions for business and is a practical
way of exploiting open systems to the advantage of an
enterprise’s business
Operational trial phase
Final proving activity of the pilot programme which occurs
during Stage 5 Operational Trials
PAN Primary Account Number. This refers to the entire card
number of a credit card. It can be up to 19 digits in length, as
specified by 1507813
PAT Project Assurance Team
Pathway Group Ltd. The company is made up of :
* Shareholders (ICL, De La Rue, Girobank)
* Principal subcontractors (An Post, Escher, A&L, BT)
¢ Financial advisor (Hambros Bank)
Payee The person who encashes/collects the benefit payment
PCRC Pathway Call Reception Centre. This is where all calls are
received for Pathway’s help desk service
PDR Postmaster’s Daily Record. This is the basis of the
Postmaster’s remuneration for Girobank transactions
PFI Private Finance Initiative. This is a procurement method by
which the Government pays suppliers to adopt a project’s
risks
PFS Personal Financial Services
Pilot programme
This covers the proving of the solution through to acceptance
of it prior to roll-out. It starts after shortlisting and ends with
agreement to roll-out
The pilot has 2 phases :
* Demonstrator phase where each shortlisted Service
Provider is given the opportunity to demonstrate their
solutions and options
* Operational trial where the selected Service Provider
further develops the solutions and selected options, and
develops the SCOP
PIN Personal Identification Number. This refers to a secret number
used to prove ownership of a magnetic stripe or smart card
PMS Payment Management System. This refers to the central
functions within the payment authorisation process which is
used for bulk processing tasks
POCL Post Office Counters Ltd. Part of the Post Office Group. One
of the two Contracting Authorities for the services described
in the SSR
Pathway Response to
OJEC Notice 94/S 165-58937/EN_
COMMERCIAL IN-CONFIDENCE Page: 6 of 9
Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 10 - GLOSSARY OF TERMS
This term : Has this meaning in this document :
POCL Strategic This refers to the areas within the Procurement Service
Infrastructure Boundary entitled : Transaction Management Service (TMS),
Operational Support Services (OSS) and Counter Interface
Service
Postmaster This terms is used to denote Postmasters and also
subpostmasters/POCL agents/post office managers
Postmaster’s pouch
Daily mail bag from post offices to the Girobank
PRINCE
PRojects IN a Controlled Environment. This is a CCTA
methodology for use in large projects
Private key
A secret value used in public key cryptography for deciphering
a message enciphered by a public key, or for enciphering a
message to be deciphered by a public key
PSTN Public Switch Telephone Network
Public key A publicly known value used in public key cryptography for
deciphering a message enciphered by a private key or for
enciphering a message to be deciphered by a private key
PUMA Prevent Unscheduled Maintenance Activity
PUN Pick up notice. This refers to the advice to benefit customers
that the post office is in receipt of something for them to
collect
Quantum The British Gas Quantum cards are smart cards used by British
Gas customers who have especially designed meters installed.
The cards are recharged at selected post offices using APT
equipment
RAD Rapid Application Development. This is a system engineering
tool
RAID Redundant Array of Independent Disks
Real time On-line and immediate
RIC Retail Integration Centre. This is located at ICL Stevenage
Riposte A product supplied by An Post and Escher. Riposte comprises
: the Desktop, the Journal Server and the Correspondence
Server. It provides the operating environment used in the
CounterAction project
RISC Reduced Instruction Set Computing
Roll-out service
The service that implements the operational services in a
planned and progressive manner
RPI
Retail Price Index
RSA
A commercially available public key algorithm named after its
inventors Rivest, Shamir and Adleman. It is a standard means
of encryption used by the US Dept of Defence and developed
at MIT
Security server
A component of Riposte which deals with the application of
digital signatures, CRC and encryption
Pathway Response to
OJEC Notice 94/8 165-58937/EN
COMMERCIAL IN-CONFIDENCE Page: 7 of 9
Date: 08/06/95
FUJ00098232
FUJ00098232
ANNEX 10 - GLOSSARY OF TERMS
This term ;
Has this meaning in this document :
Service Code of Practice
(SCOP)
The procedures written by the Service Provider, and agreed by
the Contracting Authorities, which will be used by the Service
Provider and the Contracting Authorities for the duration of
the contracts
Service level
‘An ‘absolute’ metric used to measure service quality. For
example, the maximum length of time allowed to make an
urgent payment available for collection
Service quality
Minimum standards of how the service level is achieved
Settlement Movement of money
Sherman A 10-digit unique card ID number generated during card
production. It is held on the system and also in the magnetic
stripe on the card. Every time the card is used the two are
compared
sit Systems Implementation Team
SLA Service Level Agreement. This refers to the agreement
between Service Provider and Contracting Authorities as to
the service level to be provided
Smart card Plastic card with embedded microprocessor capable of
communicating with a computer system
SMDS Switched Multi-megabit Data Service. This is a high-speed
service offered by BT
SME Small and Medium-sized Enterprises
Software agent
A component of Pathway’s strategic infrastructure which
captures and collates transactions for passing to client systems.
One variation of a software agent captures an on-line request
and passes it to a client system and then returns the response
to the local system
SOHO Small Office Home Office
SPC Statistical Process Control
SQM Strategic Quality Model. This uses the European Foundation
for Quality Management model. It has been adopted
company-wide at ICL as the overall total quality management
approach and tool
STAP Single Terminal Access Project
State message
A Riposte journal message which indicates a workstation’s
current state. State messages are based upon Riposte’s journal
message sequence numbers
Steady state services
Those services that the Service Provider will provide in the
‘business as usual’ situation following roll-out
TNA
Training Needs Analysis
Trickle-feed transaction
Intermittent transfer of transaction details that relies on a
prior electronic connection being made for another purpose
TUPE Transfer of Undertaking (Protection of Employment)
regulations
Value stock Post office sales items that have a monetary value, such as
postage stamps, postal orders and cash
Pathway Response to
OJEC Notice 94/5 165-58937/EN
Page: 8 of 9
Date: 08/06/95
COMMERCIAL IN-CONFIDENCE
FUJ00098232
FUJ00098232
ANNEX 10 - GLOSSARY OF
This term :
Has this meaning in this document :
Value token
A paper item sold by the post office that has value when it has
been completed and authorised. For example, the vehicle road
tax disk
: Verification
This is part two of the payment authorisation process that
allows the post office clerk to make a benefit payment
The process is :
Identification/Verification/Authentication/Authorisation
This term describes the process of ensuring that the
cardholder (the person presenting the card) is who he says he
is. Methods include signature, PIN, biometrics and photocards
VFM
Value for Money
VIC
Validation and Integration Centre
VSAT.
Very Small Aperture Terminal. This is a small satellite dish
Pathway Response to
OJEC Notice 94/S 165-58937/EN
COMMERCIAL IN-CONFIDENCE Page: 9 of 9
Date: 08/06/95
FUJ00098232
FUJ00098232