ICL Pathway
FUJ00117513
FUJ00117513
Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: 1.0
Date: 10/11/97
Document Title:
Document Type:
Pathway EFTPOS Host Application - Invitation to Tender
Commercial
Abstract: This document is the Invitation to Tender to procure packaged.
EFTPOS Host software from an external supplier to be
incorporated into ICL Pathway’s overall EFTPOS solution for
Post Office Counters Ltd.. The procurement includes both
software and supporting services for development, testing and
implementation of the EFTPOS solution and ongoing support
of the packaged software.
Status: Approved for Issue.
Distribution: Assessor Perspective
Tony Oppenheim Steve Reed (Commercial)
Liam Foley Dominic Barton (Business
Opportunity)
Martyn Bennett Graham King — (Risk Assessment)
Barry Procter (Security)
David Groom — (Quality)
Jan Honnor (YR2000)
Jan Holmes (Procurement
Process)
John Dicks Dave Cooke (Requirements)
Alan Ward Peter Wiles (Architecture)
Terry Austin Pete Jeram (Rel.3 Programme)
Barrie Vaughan (Planning)
Dick Long Roy Smethurst (Design)
Phil Crowther (Design)
Chris Humphries Steven Warwick (Counter Devt)
Bill Hillyard (Host Devt)
Dave Quick (Host Devt.)
Pete Sewell (Infrastructure Devt)
Gareth Jenkins (Agent Devt.)
John Wooler Simon Palladino (System Testing)
Mark Taylor (Bus. Integrity
Testing)
Steve Muchow Mik Peach (Support)
Martin Riddell (Operations)
Library Annet Fernandez
Author: Chris Plunkett
Tttlp0.doc COMMERCIAL IN CONFIDENCE Page 1 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: 1.0
Date: 10/11/97
Comments to: n/a
Comments by: n/a
Itt1p0.doc COMMERCIAL IN CONFIDENCE Page 2 of 39
© 1997 ICL Pathway Ltd
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: 1.0
Date: 10/11/97
0 Document control
0.1 Document history
Version Date Reason
0.1 1/10/97 Draft for Comment
0.2 28/10/97 — Draft for Authorisation
1.0 20/1197 Final for Authorisation & Issue
0.2 Approval authorities
Name Position Signature Date
Steve Reed Commercial
Dick Long Systems Design
0.3 Associated documents
Reference Vers Date Title Source
1 CR/FSP/0010 EFTPOS Statement of Requirement ICL Pathway
2 TD/ARC/0014 1.0 17/09/97 EFTPOS Architecture ICL Pathway
0.4 Enclosures
DISC PD2000-1 A Definition of Year 2000 Conformity DISC
Requirements (BSI)
PR10010 3 13/10/97 Vendor Evaluation (Quality ICL Pathway
Management System)
0.5 Terms & Abbreviations
ADE Application Development Environment
ALPS Automation in London Post Offices
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 3 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: 1.0
Date: 10/11/97
AP Automated Payment
APACS _ Association of Payment Clearing Services
API Application Programming Interface
BMC BMC Patrol (software package name)
BSI British Standards Institute
CUG Closed User Group
DSS Department for Social Security
EFTPOS _ Electronic Funds Transfer Point Of Sale
EMU European Monetary Union
EPOS Electronic Point of Sale
EPOSS Electronic Point Of Sale Service
FDDI Fibre-optic Distributed Data Interface
Horizon _The whole of the IT system provided by Pathway for Post Office Counters Ltd.’s
use under the PFI contract.
TIN I Identification Number
ISDN Integrated Services Digital Network
ITT Invitation To Tender
LAN Local Area Network
MA Merchant Acquirer
MIS Horizon Application — Management Information System
MoP Method of Payment
ODBC Order Book Control System
OSM Is a company name
PFI Private Finance Initiative
POCL Post Office Counters Ltd.
POS Point Of Sale
RDMS Relational Database Management System
SLA Service Level Agreement
TIP Post Office Counters Ltd. Application - Transaction Information Processing
TPS Horizon Application — Transaction Processing System
0.6 Changes in this version
Incorporates minor changes required for authorisation.
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 4 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
The version for issue to suppliers will have some sections 0.x removed as they include
purely internal, Pathway information.
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 5 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Wales 1S
Date: 10/11/97
0.7 Table of Contents
1. Instructions to Suppliers .............scsccecssesseessessessessvesseesseesnseseeesesseessessnessneeseceenssessnsess 9
LL ICL Pathway Comtact ..........ccseccececsessessesseseeseereesesnessesneneenesneceeaneseeseeneeeeeneneeseenee 9
1.2 Timetable .... 9
1.3 List of Suppliers ....
LA Submission. MeCh amis srscssscevsssra owner sacsv rescore osaanecness onsrnvanuin 10
1.5 Supplier Presentations ..............cecceceeseeseesessessesseeseseeseeseeneeeeseeseeseeneeeeseeneeteeeeeeee 10
1.6 Package Selection 0.0.2.0... cece eeeeeeeee ee eeeee ee eeeeeteeeeteeneeeeeeeteeeeeeeeeees LO
1.7 Agreement...
1.8 Confidentiality 22... ceseeecesecsessessesseseeseesesneeseseeseesesneeecsnereeneanereeaeeneeneaneeees 11
1.9 Pathway Obligation 0... ees eeseeeeeeeeseeseeeseeneeeeeeeseeeeeeneeneeeeeeeeees LL
2. Background ooo... .ecesceseeseeseesessessesseeessesscesesuceeesessessesuseesausaeeseanseessneseeecenseesaeeneeeaneees 11
3. Purpose 12
4. Business Requirements
5. TECHNICAL REQUIREMENTS .
4.1 Post Office Counters Ltd. Business Context............00-ccseeseessessseeseteeseneeeseeees 13
4.2 Business Rules ..............csceccecssesseesseeseeseseneeseesneesneeseesseeseesseesneesseneesessneeaneenense 14
4.2.1 EFTPOS Business Rules.............cccecccecsseessesesseessesssneessesesnseenneseseneenees 14
(43 BUSiNess PROCCSSCS x. ssscc. rssceecrsseees ssceerussis a westerns ieee tamer 15
4.3.1 Card Recognition and Data Entry 0.0.0.0... cesses eeesee tenes teeeteeeeeeeeeeee LS
4.3.2 Authorisation............c.cccsccecssecseessessneesesseesseesseesnseseeevesseesneesneeseeevessesaneesnse 15S
4.3.3 Submission... ceccsseccseecsseeesseeseseesseeseseeeoseesesesesneessensesnseenesesneeeanees 16
4.3.4 Reconciliation... ceeccceecseecsssecssecesneesseesesneessessssessseessseeesseessssssseesseees LT
4.3.5 Integration with Other Processes ...........0..ccesseseeeeseeesesteseeeeeeeeeeeeeeeeee 17
4.4 Volumes
4.5 Other EFTPOS Host Software Usage .
4.6 Smart Card Capability.
5.1 PROPOSED EFTPOS ARCHITECTURE
5.1.1 Application Architectures
5.1.2 Platforms
5.1.3 Networking Services.. 21
5.1.4 Information Management ................ccsesseseesesseesesseseeseeseeeesneseeseeseeseeneeeeeses 22
Tttlp0.doc COMMERCIAL IN CONFIDENCE Page 6 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: 1.0
Date: 10/11/97
5.1.5 Distributed Application Services ..............c.c cece estes esses eeeeeeenesneeeeeees 24
5.1.6 User Interface ...........ccecccecseessecsnecsesseeseesseesnseseesieeseesseesnessessnesnessneeaneenense 24
5.1.7 Application Development ...............ecscsseseesessessessereeseereeeesneseeseeneeseeneeeeenes 25
5.1.8 Systems Management ..........2.....:c.scesseseeseesees ects ee eeseeseeeeeeetesneeeeseeneeeeenes 25
5.2 EFTPOS Service Qualities... cccccssesessesessesesesesesseseeeeeseseseseneeeeteesseseaneneees 26
5.2.1 Usability cece eeccseesseeeeseesseeeeneesseessneesneserineesneessneeseesseeeeneessnee 26
5.2.2 Performance ............eesceeecseeesseessseeesseeeeneeesseeseeeesneesnneesneesneneraneesnenseseeenee 26
5.2.3 Potential for Change ...............:ceceeesseses ees eeseesesseeeesneeeeneentetesnsetssnenesseenee 27
5.2.4 Availability..........ccceeceeccsseesseecesesssessseeesseesssecesneressesesnessnvesesnessnesennessnee 28
5.2.5 SOCUTILY ....ceeeeececeeceseeseeseesesesseeseseescesesncesesseseesesnesseseeseeesaneeuesneaeesteneeeeenes 29
5.3 interfaces ees sess eeeeseeesseeeesneesseeseeneesneesnseeesneesneesesneessesesntessensssesesseeeseees 3O
6. Standards.............
6.1 APACS Compliance ..0.......c.ccecceeeeeeeseeteeneeeeseeseesesneeeenereetesneeteteeenteneeeeneneene SD
6.2 Year 2000 Compliance ...........eeceeceesecseesessesseseeseesesseeseseeeeseeressesnereeseeneeeaeeeee 31
6.3 EMU Compliance ...........cececcecceseeseeeeeeeeeeceeeeeeeseeseeenee ses neeeeaeeneettanee tenses 3D
7. Supporting Services 2.2.2... eee eeseesessesseeseseeeeesessessesseeeeseseeeesuseesseeneeeesnseeeseeneeeaneees 34
7.1 Documentation... .cccceccseesseessseesseessseesstesesneesneeeesneessiseesneesnneeseesneeseieeesnee 34
7.2 Installation Services ...........eesceeesseesseeessseeeseeeseesseeesneesseesrseesnenseineeeneeseseeesnee 34
7.3 Customisation Services ............cccecseeccecseecseessessesssesseesseesneesneeneeseesseesnessneeseesenes OA
7.4 Consultancy Services ..........ceccecssecsesssecseesseesseesesssesseessessneesesenessecsneeaneeseeneeeseess 34
7S Training Services ........e.ceeseesecesseesesseseeseeseesessesseseeseesesneseseereeeeaneseesneseeseeneeseanes 35
7.6 Upgrades ......cccecececcececcesecsecsecseseesneeceeseeesesnseesanesteatsneeteansetententestsneeteenenseeeeees 3D)
7.7 Support Services .........c.ccecesescesseseeseeseesesseeesseeeesessessesneeeesuseesuesnseessneeeeeeeneeeeeees 35
8. Implementation Plan ...............eeeeeessesseseseesesseesesseseeseeneesesneseeatsneeseaneeeeseeeeeseeneeeenes 35
8.1 Business Priorities... cesses cess tees tees eeeeseeesseeesnessnensesneessensesneteneeseeeessnee 35
8.2 Implementation Proposals .................cscscsesses esses ees eeeeseee teense eeeeneeteeneeeeseeneeeene BO
8.3 Sub-comtracting oo... cece eeeceeeeseeseesesseesesneeesseseessesneeeeseseeeeeeneeeesnseeeeeeneeeeanes 36
9. Supplier Appraisa
9.1 Financial
9.2 Implementation
9.4 Package Stability
9.5 Service Assurance ..
10. Commercial
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 7 of 39
ICL Pathway Pathway EFTPOS Host Application -
Invitation to Tender
FUJ00117513
FUJ00117513
Ref: EF/DOC/001
Version:
Date:
1.0
10/11/97
10.1 Price Summary ............cccesees cece ee sess eseeseeeeseeseseeesnseeesesneetssseeesiessestesseeesaeeeeeeee OT
10.2 Once Only Costs .......eececceseeseesessesseseseeseeseesesneeeeseeeeesesneeessnsseeseaneeseaneneeneeeeseee 37
10.3 Recurring Costs ..........csccsessesessessessesesesesreesesnesseseeeesesneecseereeneaneeteaeeneesaneeeee 38
10.4 Contract 38
10.5 Intellectual Property Rights.............0.cccseeseesees cesses eeeseeeeeseesesseseesenteneeeeneeeeee 38
10.6 Performance and Liability... eeceseeeeseceeseeseesesseeeeseeseeenneeteneeneeeeneeeees 38
10.7 Warranty and Support ............c:ccecceseeseesesseesesnesseseeseeseeneeeeseereeseeneeeeseeneeneaeeeee 38
Itt1p0.doc
COMMERCIAL IN CONFIDENCE
Page 8 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
1. Instructions to Suppliers
1.1 ICL Pathway Contact
Contact Chris Plunkett
Address ICL Pathway
Forest Road
Feltham
Middx
TW13 7EJ
Telephone c
Mobile
Fax Peeters 3
1.2 Timetable
Task Start Complete
ITT issued 21/11/97
Responses received 05/12/97
Proposal Evaluation & Taking Up References 08/12/97 19/01/97
Christmas Break 22/12/97 02/01/98
Supplier Presentations 05/01/98 14/01/97
Shortlisting (to one supplier) 15/01/97 23/01/98
Package demonstration/evaluation 26/01/98 20/02/98
Agree contracts 26/01/98 20/02/98
Order placed 27/02/98
Completion of the design, development, test and integration, implementation and
acceptance phases (including MA acceptance) is planned for the remainder of 1998.
1.3 List of Suppliers
The following suppliers have been asked to tender:
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 9 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
¢ Checkline
¢ CommsXL
e Retail Logic
1.4 Submission Mechanism
A virus checked 3.5” diskette containing this and 2 other associated documents in
Microsoft Word 6.0/95 format is enclosed
Your response should be submitted on a virus-checked diskette using the same
Microsoft Word 6.0/95 format.
In addition, a paper copy of your response should be provided in a loose-leaf binder,
preferably in A4 format. You should supply 6 copies of any other documents
supporting your proposal.
Printing should be on one side of paper to allow annotation by readers.
Responses should be marked Commercial In-Confidence on each page.
Suppliers should provide responses to all the requirements identified
[REQUIREMENT] below.
Requirements are classed as Mandatory, Important or Desirable.
Please reference and follow the order of the ITT paragraph numbers in your response.
If suppliers feel there are omissions in the requirements they are encouraged to add
further information in their proposal.
1.5 Supplier Presentations
After tenders have been submitted, ICL Pathway will invite suppliers to Feltham to
present their proposals.
1.6 Package Selection
ICL Pathway will take up references provided.
ICL Pathway will short list one supplier based on the proposals and the response
indicating the ability of the proposed package and supplier to meet the various
requirements defined in the ITT.
ICL Pathway will ask the short listed supplier to demonstrate the ability of the
package to meet evaluation criteria which will be based on the ITT requirements and
the supplier’s response. This will be a precursor to any contractual agreement.
1.7 Agreement
ICL Pathway will enter into contractual negotiations with the shortlisted supplier.
Note: ICL Pathway is not obliged to enter into agreement with any supplier.
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 10 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
1.8 Confidentiality
This ITT is Commercial In-Confidence and should not be disclosed to any third party
without prior approval from ICL Pathway.
Suppliers have already signed an ICL Pathway Confidentiality Agreement.
1.9 Pathway Obligation
2. Background
January 1997 - Press Release
ICL Pathway a wholly owned subsidiary of ICL, is working with The Benefits Agency
and Post Office Counters Limited to deliver a multi-million pound automation project
which will transform post office shopping throughout the UK.
The new system will enable delivery of more services over post office counters and
when fully implemented is expected to virtually eliminate fraudulent benefit
encashment, resulting in significant fraud. Post Office Counters Ltd. will also benefit
from counter automation bringing efficiencies to its non-benefits business e.g. product
and license purchase, automated bill payments, etc..
This is one of the government’s largest private finance initiative (PFI) projects and
involves the automation of 20,000 post offices in the UK, the training of over 60,000
post office staff and the design and integration of a system for making benefit
payments through post offices. ICL Pathway will deliver a card-based benefit payment
system to replace girocheques and order books. The Payment Card will gradually
replace order books and girocheques for all of the 19 million people who collect DSS
benefits through post offices in the UK. Currently some 890 million order book and
giro cheques are made through post offices each year.
The first phase of the Payment Card launch is already under way in ten post offices in
the Stroud area of Gloucestershire and will involve more than 1,400 people receiving
Child Benefit from the ten post offices.
ICL Pathway (now a wholly-owned subsidiary of ICL) was founded by ICL,
Girobank, and De La Rue. Its chairman is Sir Michael Butler, a director of Hambros
Bank which is financial advisor to ICL Pathway. Keith Todd, chief executive of ICL,
is deputy chairman.
As well as a breadth of understanding of benefit systems and counter automation, each
of ICL Pathway’s founders has expertise in its particular field: complex systems
integration projects (ICL), cash handling and payment processing (Girobank) and
secure payment systems and card technology (De La Rue).
ICL Pathway’s principal sub-contractors are:
+ ICL, providing system integration, overall programme management, central
systems operation, training and roll out
* Girobank, providing help desks and fraud risk management
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 11 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
+ De La Rue, providing benefit card production and distribution
+ An Post (The Irish Post Office), providing post office consultancy and counter
automation
+ Escher group (USA) - counter automation and consultancy
* Oracle Corporation - software development
* Microsoft - the software platform
* McCann-Erickson - advertising and promotion
ICL Pathway’s experience in counter payment systems includes the Republic of
Ireland where An Post has installed over 600 offices. To date, this has brought a
number of advantages to customers in terms of user-friendly cards and a speedy and
enhanced range of services.
In addition, in the UK the ALPS project (Automation of London Post Offices) was
awarded to ICL in late 1994. This involved installation of new systems at 4500
counter positions in 1500 post offices within the M25 area. Completed in August
1995, this has already led to a substantial reduction in benefit fraud.
ICL Pathway is responsible for the introduction of the benefit Payment Card and for
bringing technology to post offices under the government’s private finance initiative
(PFI) scheme. It is supplying an integrated system and services which will improve the
performance of customers’ businesses.
The company bid successfully against several other businesses to win the contract
which is one of the largest PFI contracts ever awarded. Employing over 100 people, it
is a wholly owned subsidiary of ICL and is headquartered at Feltham in Middlesex.
ICL is a leading European information technology company, operating in over 80
countries, it supplies integrated systems and services.
3. Purpose
To deliver an EFTPOS Service to Post Office Counters Ltd. as part of its Horizon
solution, Pathway wishes to procure EFTPOS Host software to run as a centralised
service, supporting EFTPOS authorisation, submission and reconciliation. Pathway
will also procure associated professional services.
Post Office Counters Ltd. wishes to introduce EFTPOS into Post Offices to support a
variety of Card Schemes. These will initially include debit cards but will in the future
include credit cards.
Post Office Counters Ltd.’s requirements are that an EFTPOS facility should be
provided supporting debit cards and credit cards as additional Methods of Payment
(MoP) within the Electronic Point of Sale Service(EPOSS) and that standard APACS
authorisation, submission and reconciliation methods should be supported. The
expectation is that the service should support a variety of authorisation methods
including Hot Card lists and on-line authorisation to one or more Merchant Acquirers.
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 12 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
4. Business Requirements
Suppliers are asked to show how their software supports the business requirements
described in the remainder of this section.
In their responses, suppliers should state the availability of functionality being
proposed.
4.1 Post Office Counters Ltd. Business Context
In general Post Office Counters Ltd. acts as an agent for its clients and outlets act as
sub-agents to Post Office Counters Ltd.. Various agreements govern these
relationships.
Among other things, the agreements define which client products and transactions
Post Office Counters Ltd. will trade and the range of these products and transactions
an outlet will trade.
EFTPOS will be available in all automated post offices.
Business rules are defined to govern product transactions.
A customer session may include one or more product transactions between the
customer and the outlet.
The customer may use more than one Method of Payment (MoP) to settle individual
product transactions or customer sessions.
EFTPOS introduces two new MoP - debit cards and credit cards.
Post Office Counters Ltd. will initially appoint one or more Merchant Acquirers to
handle its EFTPOS business. Their agreement will identify a number of EFTPOS card
schemes. There will be a number of different card issuers for each scheme. Each card
has a unique issuer identification number. The number of issuers changes frequently,
so it is usual to allocate a range of IINs for a card scheme to reduce the administrative
load. Post Office Counters Ltd. and the MA will negotiate a number of business rules
e.g. transaction ceiling for each card scheme. Post Office Counters Ltd. may add its
own rules e.g. minimum EFTPOS transaction value.
As with other MoPs, individual product transaction business rules will specify
whether debit card or credit card is an allowable MoP.
Customers will present an EFTPOS card to support an EFTPOS Payment Transaction.
Cards are recognised using the magnetic card identification details associated with
each EFTPOS card scheme.
All EFTPOS Payment Transactions are required to be authorised - the result is
recorded. EFTPOS Payment Transactions may be committed or voided - details are
recorded.
EFTPOS Refund Transactions are also supported.
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 13 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
4.2 Business Rules
4.2.1 EFTPOS Business Rules
To minimise transaction times and the number of ISDN calls from the post office to
the centre, ICL Pathway’s policy is to evaluate as many business rules as possible
before making such calls. Suppliers’ EFTPOS package application interfaces may
require them to be evaluated at the centre.
ICL Pathway suggests the following breakdown between host and counter
implementation:
Host
¢ Routing of authorisations and submissions for card schemes and card types
between multiple MA’s
© Hot Card Lists to identify cards which may not be used (initially none).
¢ Enforcement of Floor Limits below which Post Office Counters Ltd. can authorise
transactions (initially £0 requiring 100% on-line authorisation)
¢ Enforcement of Cash Back Floor Limits below which Post Office Counters Ltd.
can authorise transactions.
e Enforced on-line authorisation for particular card scheme.
e Whether the merchant can perform stand in authorisation if the Merchant Acquirer
doesn’t respond within a set time (initially Post Office Counters Ltd. want to
DECLINE such transactions).
e Limit on the number of transactions a particular card is allowed to do each day.
e Enforced on-line authorisation every N transactions done in a post office.
e Enforced authorisation if a card is used consecutively in the same outlet.
Counter
¢ Card validation
¢ Card scheme/type accepted
© Card expired
© Card start date not yet reached
¢ Ceiling Limits limiting the maximum value of transactions.
e Cash Back Ceiling Limits limiting the maximum value of transactions (initially £0
to prevent cash back).
e Cash Back transactions must have a positive purchase element.
e Whether card details may be entered manually.
e¢ Minimum EFTPOS transaction value for particular MoP defined by Post Office
Counters Ltd..
¢ Refund allowed for particular card scheme.
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 14 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
¢ Refunds allowed for the product.
¢ Restriction on which products can be paid for with debit cards.
¢ Restriction on which products can be paid for with credit cards.
[REQUIREMENT 1I - MANDATORY] Suppliers must:
e describe how the breakdown (host to counter) of requirements above is met or
propose an alternative breakdown required by their package application
interfaces.
4.3 Business Processes
4.3.1 Card Recognition and Data Entry
This is counter system functionality and is included here purely for completeness.
Magnetic card details are swiped in via the card reader. Individual cards, or ranges of
magnetic cards, are recognised as EFTPOS cards.
If the card cannot be read, the EFTPOS method of payment may be selected and the
card details input manually if allowed for the particular card.
There is a list of allowable methods of payment for each product.
Some initial verification is done here:
Additional data is entered e.g. payment value.
4.3.2 Authorisation
Every EFTPOS transaction is required to be authorised either by Horizon or on-line by
a Merchant Acquirer. Telephone authorisation is used as a fallback service.
A number of business rules must be checked against criteria for individual card
schemes:
The business rules identified above may trigger Horizon or MA on-line authorisation.
The EFTPOS Host software or Merchant Acquirer will either authorise or decline the
request.
The system will record authorisation responses.
For authorised transactions, the counter system will print an EFTPOS Transaction slip
for the customer to sign. The clerk checks the signature and commits or cancels the
EFTPOS transaction as appropriate.
The clerk can also cancel a transaction at the customer’s request. Cancelled
transactions must be recorded for reconciliation against authorisations. If the
authorisation was from a Merchant Acquirer, the Merchant Acquirer must be notified
(the MA needs to amend the customer’s available credit to reflect the cancellation).
[REQUIREMENT 2 - MANDATORY] Suppliers must describe how their software:
¢ enforces authorisation business rules
© supports on-line authorisation
Tttlp0.doc COMMERCIAL IN CONFIDENCE Page 15 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
© supports stand-in authorisation (by the host software)
e records authorisations
¢ handles cancelled authorisations
4.3.3 Submission
EFTPOS payment transactions are batched into files which the Merchant Acquirer
collects periodically (assumed to be several times per day).
The Merchant Acquirer will acknowledge the batch. The batch may need to be resent.
Merchant Acquirer may also request (later in the day) the batch be resent. An
alternative strategy adding these transactions to a later batch must also be supportable.
Post Office Counters Ltd. has not specified which strategy is to be adopted.
[REQUIREMENT 3 - MANDATORY] Suppliers must describe how their software:
e accepts EFTPOS transactions from the counter system for submission
© supports multiple Merchant Acquirer submissions
* creates submissions
e enables the MA to collect submissions
© manages the submission interface with the MA
e handles re-submissions (both file and transaction modes)
e handles different types of EFTPOS transactions e.g. refunds
e handles manually authorised transactions
e handles multiple submissions (to a Merchant Acquirer) in one day
4.3.4 Reconciliation
Pathway Reconciliation
Horizon should hold a record of EFTPOS authorisations (accept or decline) and
subsequent EFTPOS payments and cancellations plus any manually authorised
transactions.
Except for the manually authorised transactions, these should reconcile but not
necessarily immediately e.g. payments relating to authorisations may not yet have
been submitted to the MA.
Elsewhere, Pathway has used a rolling, daily reconciliation report, tabulating a N day
window showing the state of reconciliation to date.
[REQUIREMENT 4 - MANDATORY] Suppliers must:
e describe how their software supports this reconciliation function
© comment on the provision of rolling reconciliation reports
MA Reconciliation
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 16 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
At some point it will be necessary to reconcile Horizon’s view of value of transactions
with the MA’s view after any amendments due to MA and customer queries.
[REQUIREMENT 5 - IMPORTANT] Suppliers must:
¢ propose, from their experience, a strategy for MA reconciliation.
4.3.5 Integration with Other Processes
Payment transactions are also be submitted to other Pathway and Post Office Counters
Ltd. systems but not by the MA submission sub-system being procured.
4.4 Volumes
Post Office Counters Ltd. estimates are as follows :-
e Between 30 million and 50 million EFTPOS transactions a year across the Post
Office’s network of 19,500 post offices
e Assume 305 days per annum (Monday - Saturday operation) and 8 hour opening.
e Peak month (December) rates are estimated at 2 times the average.
e Peak hour (midday) rates are estimated at 3 time the average.
¢ 70% above floor limit (assumed at £15). This will be 100% initially, i.e. all
transactions will require Merchant Acquirer authorisation.
e EFTPOS is expected to be used against the following transactions :
Motor Vehicle Licence renewals - 34%
Bill Payments - 38% (approx. half for BT)
TV licence -11%
Post Shop purchases - 5%
[REQUIREMENT 6 - MANDATORY] Suppliers must:
¢ substantiate that their software components can support the required volumes
© state any assumptions regarding the hardware and software configuration required
to support the required volumes e.g. number and size of servers, network
connections ete.
4.5 Other EFTPOS Host Software Usage
Pathway’s Development function will require 1 development system.
Pathway’s Test and Integration function currently employs 9 separate test rigs, all of
which may require EFTPOS Host functionality.
Pathway’s Operations function currently employs 3 separate test rigs, all of which will
require EFTPOS Host functionality.
The number of live operational licences (minimum 2 sites) is dependent on transaction
volumes (see 4.4 above).
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 17 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
[REQUIREMENT 7 - MANDATORY] Suppliers must:
e Ensure provision of development and test licences are covered in their costings as
well as those required for live systems.
4.6 Smart Card Capability
Whilst the current requirement is specifically for magnetic card based EFTPOS
functionality, smart card technology will be required in the future.
[REQUIREMENT 8 - IMPORTANT] Suppliers must:
e indicate a forward path from their proposed magnetic card solution and provide
any other information they feel is relevant regarding their competence in this area
5. TECHNICAL REQUIREMENTS
Suppliers are asked to show how their software meets the technical requirements
described in the remainder of this section.
In their responses, suppliers must state the availability of functionality being
proposed.
5.1 PROPOSED EFTPOS ARCHITECTURE
Horizon is ICL Pathway IT solution for Post Office Counters Ltd.
5.1.1 Application Architectures
In line with Horizon standards, each application is to be implemented as a vertical
stripe across a number of standard horizontal enabling layers, as shown in Figure 1.
Figure 1 - Application Components
Thus, within this architecture, the structure of an EFTPOS application is as shown in
Figure 2.
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 18 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
‘Submission
Service
On-Line
Authentication
Authentication, Submission &
Reconciliation Host
Card reader
Co
Commit Authenticate
Transaction II Transaction
Figure 2 - EFTPOS Architecture
Horizon employs Riposte, a 3" party software package, to provide a resilient
infrastructure to support post office counter applications (see Figure 2). This uses a
replicated messaging strategy across multiple Correspondence Servers in 2 Area
Computer Centres (known as Campuses) whereby messages are replicated between
the 2 sites on several servers.
Post office to campus communications uses ISDN. An alternative satellite based
communication service is proposed for some outlets.
Within the Counter and Correspondence Server environment, EFTPOS authorisation
requests and responses and resulting EFTPOS transactions will be implemented using
Riposte messages.
The Authentication Agent will pick up authentication request messages and pass them
to the the EFTPOS Authorisation Host package’s application interfaces. It will return
the authorisation response to the counter system via Riposte.
Similarly, the Submission Agent will periodically ‘harvest? EFTPOS transaction
messages from Riposte and pass them to the EFTPOS Submission Subsystem.
The Riposte layer provides transaction integrity. How this is promulgated across the
EFTPOS Host package boundary and subsequent MA boundary is to be proposed by
suppliers. This requirement is specified in the later section on Availability.
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 19 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
Horizon has a managed, 2 Campus operation which may be employed to provide
EFTPOS Host resilience. It has high speed WAN links between the Campuses.
EFTPOS Agent and Host subsystems and the necessary MA communication links will
be available at both sites. A strategy for resilience and recovery will need to be
devised post contract, however, suppliers must relate their experience of similar, dual
campus solutions. This requirement is specified in the later section on Availability.
Use of Third Party Applications
Horizon’s architecture does not allow 3“ party applications to co-exist with Riposte
on the Counter or Correspondence Servers.
Agents are required to bridge between Riposte on the Correspondence Servers and
Host applications.
3" party packages may be used to deliver Host application functionality.
[REQUIREMENT 9- MANDATORY] Suppliers must:
e describe how their software fits the proposed application architecture
5.1.2 Platforms
5.1.2.1 Agent Platforms
EFTPOS Agents will run on Windows NT 4 Servers within each campus.
5.1.2.2 Host Platform
EFTPOS Hosts will run on Windows NT 4 Servers within each campus.
A Host-to-MA interface is required, supporting file transfer and used for passing
transaction data to the MA on demand.
The Agent and Host functions should be hosted on the same server. A separate
submission server may be required if the submission host incorporates an MA
supplied, DOS based, MA interface function.
[REQUIREMENT 10 - MANDATORY] Suppliers must:
¢ confirm support for Windows NT 4 (with Service Pack 3) and experience in using
it
Note: Pathway has configured Windows NT for Security purposes so some NT
functions may not be available - Pathway will need to check supplier’s package
dependencies on NT functions during package evaluation.
¢ confirm experience of using different manufacturers NT systems
e propose a configuration (of one or more physical servers) to support the
authorisation, submission and reconciliation functions.
5.1.3 Networking Services
Communication between Counter and Data Centre will use the standard features of
Riposte and ISDN. Authentication messages will be sent as Priority Riposte messages,
and hence will raise the ISDN line if it is closed. Subsequent EFTPOS transactions
will be sent as Non-Priority messages.
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 20 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
An Agent Process in the Data Centres will wait on this class of message, using a real
time message port, and on receipt of one will transmit it via the Authorisation Service
to the Merchant Acquirer.
Data transfers to and from the Merchant Acquirer are usually via X.25, and hence an
X.25 interface is required out of the Data Centres. This is most easily achieved by the
use of a pair (for resilience) of small CISCO Routers dedicated to the interface to the
MAs!. These will be configured to support an X.25 Closed User Group (CUG)
containing only the ICL Pathway Routers and the Merchant Acquirer Routers. The
Authorisation Server sends an IP Datagram with a destination address of X, where X is
within the ICL Pathway address space.
The Routers advertise services to address X and perform Network Address translation
to map X to X/ where X/ is in the IP address space of the Merchant Acquirer system.
They only accept Datagrams from the Authorisation Service, and then validate these at
level 3 and level 2. This gives a high degree of confidence that any successful
penetration of the Pathway systems will not permit easy onward attempts to
compromise the MA systems.
X.25 lines often restrict the number of concurrent connections, and hence we need to
determine the expected peak message rate and calculate the number of lines required
accordingly.
Host Data Mis
Warehouse
FDDI
[ [ [
[re II Agents 7 Routers I I [ Agent
100baseT
c c
Correspondence Correspondence
Server I} Server
i
I
ISDN
Router
Figure 3 - ICL Pathway Campus Communications
[REQUIREMENT 11 - MANDATORY] Suppliers must:
1 The existing WAN Routers could be used, but this approach is simpler
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 21 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
¢ propose how their software would fit this architecture
5.1.4 Information Management
ICL Pathway’s strategy is to use Riposte’s message replication functionality for
securing data. The use of RDBMSs purely for this purpose should be unnecessary but
they may be required for other purposes.
5.1.4.1 Data Associated with EFTPOS
§.1.4.1.1 Card Scheme and Card Type Information
Information pertaining to the Card Schemes supported, to their associated Card Types
and their IIN, and to floor and ceiling limits, will be maintained in the Horizon
Reference Data database. From here it is distributed to other host and counter
subsystems.
Hot Card Lists will be supported by the EFTPOS Host Subsystem. Data will be
provided electronically by the Merchant Acquirers.
All Hot Card Lists will be implemented centrally. There is no plan to distribute Local
Hot Card Lists to outlets.
§.1.4.1.2 Authentication Requests
Authentication Requests to Merchant Acquirers follow the APACS 30 standard.
5.1.4.1.3 Submission Data
Transaction submission to the Merchant Acquirers follows the APACS 29 standard,
which involves file transfer of flat files.
Horizon usually harvests transactions in batch mode on a per outlet basis and could
pass these to the EFTPOS server application in batches or as individual records.
There is a working assumption that there will be several submissions to MAs per day.
An MA may indicate that a particular file transfer failed, in which case the designated
file may be retransmitted.
The MA will provide electronic feedback on the outcome of it processing pervious
submissions.
The alternative resubmission strategy to include transactions from the failed file
transfer in the next regular batch instead of re-transmitting the original file must be
supported.
5.1.4.1.4 Reconciliation Data
A database of EFTPOS authorisations and transactions will need to be maintained for
reconciliation purposes. Reconciliation reports will be produced - probably daily.
[REQUIREMENT 12 - MANDATORY] Suppliers must describe the databases
provided and any database management services required to manage them and provide
database sizing for:
© card details
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 22 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
¢ business rules
e hot card lists
© authorisations
¢ submissions and acknowledgements
¢ submission reports
© reconciliations
¢ any other databases e.g. for administration
5.1.4.2. Data Flows
These are shown in Figure 4.
_ ‘ i POCL POCL TIP
[Voice authentication
eet Merchant Operational limits I peference ‘System
Acquirer Tate Data
Voice
jauthorisation Hot card file] ISubmission file loperat-
request Submission acknowledgment] (APACS 29) lional
Reports limits
Operational limits I Icard
Card Parameter Data_I [Parameter
Horizon Host Data
System IProduct
reference
Counter! I Hot card File data
transactionsI I (ifn Agent)
Authorisation]
requestI Authorisation Horizon
(APACS 30)I fesponse Agent Counter transactions
System
Authorisation request! IOperational limits
(Riposte) ICard Parameter Data
IProduct reference data
uthorisation response
Counter Horizon
Staff Counter
a Fall back System
transactions
IEFTPoS card
Transaction request
Customers
Figure 4 - Data Flows
Provided for information.
5.1.5 Distributed Application Services
EFTPOS transactions use the Riposte middleware in the same way as other Counter
transactions, and no changes are required.
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 23 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
5.1.6
5.1.7
5.1.8
5.1.8.1
5.1.8.1.
MAs often supply specific software to manage the EFTPOS Host - MA interface. This
is often DOS based software and, because of this, the submission subsystem may run
on a separate Windows-NT server if required.
[REQUIREMENT 13 - MANDATORY] Suppliers must:
e describe any MA interface technology employed
e describe any other middleware employed elsewhere
User Interface
ICL Pathway’s policy for system management prefers APIs for administration and
control of packages, however, there is likely to be a User Interface for these functions
as well.
In addition user interfaces may be required for product support purposes.
[REQUIREMENT 14 - MANDATORY]] The supplier must:
¢ describe the interfaces provided for service administration
e describe the interfaces provided for service control
e describe the interfaces provided or required for product support
Application Development
Riposte’s application development toolkits will be used for Counter and Agent
development.
[REQUIREMENT 15 - MANDATORY] Suppliers must:
© provide details of the application development environment required to use
application programming interfaces provided.
Systems Management
Horizon uses Maestro (sourced from Unison Software/Sequent) to schedule NT
workloads.
Horizon uses Tivoli (sourced from IBM) to manage software distribution and
operational alerts on NT hosts.
Horizon uses PCMS for storing and managing system software components.
Pathway System Mgt. Policy for NT Platform Based Applications
1 Software Distribution
e packages should be well defined
© unattended installation should be possible
© software fixes should be able to be applied incrementally
¢ software should be storable and distributable from a configuration management
system such as PCMS
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 24 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
5.1.8.1.2 Event Management
e packages must use NT event log
© event messages must be documented with associated recovery actions
5.1.8.1.3. Resource Monitoring
e packages should be self managing i.e. do their own housekeeping
e if not, required housekeeping operations must be documented
§.1.8.1.4 Diagnostics
© must be documented
e should be controllable via API’s
¢ results must be documented
5.1.8.1.5 Management of the Configuration of the Application
¢ must be documented
¢ should be controllable via API’s
5.1.8.1.6 Performance Monitoring
e should use NT performance tools
[REQUIREMENT 16 - MANDATORY] Suppliers must:
© comment on their package’s conformance with this policy
5.1.8.2 SLAs
MAs typically specify and agree SLAs for authentication response times and for the
availability of reconciliation data from retailers. The design must include the use of
time stamps at all parts of the authentication, submission and reconciliation processes
so that the conformance to these SLAs can be calculated subsequently and statistics
gathered.
[REQUIREMENT 17 - MANDATORY] Suppliers must:
e describe how service monitoring may be achieved e.g. of MA interfaces
5.2 EFTPOS Service Qual
ies
5.2.1 Usability
[REQUIREMENT 18 - IMPORTANT] There are no specific usability
requirements for host services unless they mandate user interfaces for package
administration and control, in which case, suppliers must:
e describe the usability attributes of the interfaces supplied
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 25 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
5.2.2 Performance
The key constraints is the time taken to authenticate a transaction. This will be mainly
influenced by the time taken to return the authorisation from the MA, and this can be
very slow, particularly in December. Note: MAs may use stand-in authorisation if the
particular bank does not respond quickly enough.
The merchant can also perform stand in authorisation if the MA response time
exceeds limits. Post Office Counters Ltd do not want to do this at this time, however,
the EFTPOS Host software should support it for the future.
The Horizon architecture will add its own delays to the MAs authentication process.
These will be of the order of three seconds.
There is a nominal 8 seconds target for authorisation. Horizon is expected to consume
3 of these. The remaining 5 seconds is available to the EFTPOS Host and MA to
process the authorisation.
[REQUIREMENT 19 - MANDATORY] Suppliers must:
¢ substantiate the performance of their software given the volumes of transactions
expected
5.2.2.1 Volumetrics
Estimates from Post Office Counters Ltd. are given in Chapter 3. The impact of these
on the Horizon architecture is estimated as follows.
§.2.2.1.1 Transaction volumes
The transaction authorisation volumes during peak times may require multiplexed
interfaces with the MA’s .
[REQUIREMENT 20 - IMPORTANT] Suppliers must:
¢ confirm their support for multiplexed interfaces
5.2.2.1.2 Hot Card files
= Post Office Counters Ltd. are unlikely to require the use of hot card files at
first release. When they are supported, Horizon will support the capability
to use them. Following the EFTPOS market trend, Pathway intends to
implement all Hot Card Lists centrally.
When they are introduced it is likely that the standard sized files from the Merchant
Acquirer will be used. There are 80,000 entries in the central file. A full replacement
will be issued daily from the Merchant Acquirer.
5.2.3 Potential for Change
Much of the detail surrounding the implementation of EFTPOS will be driven by
Reference Data, and hence will be easily changeable by use of the Horizon Reference
Data Management Service (RDMS).
Issues likely to require more fundamental changes include:
¢ introduction of new Card Schemes (e.g. Solo) with their own rules of engagement
Tttlp0.doc COMMERCIAL IN CONFIDENCE Page 26 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
¢ introduction and/or replacement of MAs
¢ implementation of credit cards
¢ implementation of cash back
* amove towards the use of Smart Cards for EFTPOS
e Packaged solutions may offer functionality enabling further business opportunities
e.g. loyalty card schemes, stopped cheque or bank account checking, checking
withdrawn licences, etc.)
[REQUIREMENT 21 - MANDATORY] Suppliers must assess the impact of:
¢ introducing new card schemes
© introducing new MAs or changing MAs
¢ introducing credit cards
e introducing cash back
e the future migration to smart cards
and show how their system will be able to incorporate the changes
[REQUIREMENT 22 - DESIRABLE] Suppliers are invited from their experience
of the marketplace to:
e identify other opportunities for merchants using the proposed and associated
software packages in their portfolio
5.2.4 Availability
The EFTPOS system should provide mechanisms to cater for system failure.
5.2.4.1 Outlet Failure
5.2.4.1.1 Card Reader Failure
If the card reader fails, and the card scheme allows, card details will be input manually
and the transaction will continue as usual although the card details in the transaction
will be marked as manual entry.
5.2.4.1.2 Authorisation Failure
If authorisation cannot be obtained (e.g. because communications to the centre are
unavailable) the EFTPOS transaction will be continued manually and resulting details
input via the keyboard. Telephone authorisation from the MA is required. The
resulting EFTPOS transactions will be marked as having been input manually.
5.2.4.1.3 Counter System Failure
If the counter system is not functioning, the clerk will perform both EPOS and
EFTPOS functions manually. The latter will require the clerk to obtain voice
authorisation from the Merchant Acquirer. When the counter system is restored the
system should be able to record the method of authorisation (i.e. voice and any
authorisation code) as part of EPOS transaction recovery.
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 27 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
This assumes that the Outlets have access to a conventional “zip-zap” card machine,
and that the slips from this may be used to enter the transaction details later. The
resulting EFTPOS transactions will be marked as having been input manually.
5.2.4.2 Agent or Host Failure
The Riposte layer provides resilience at the Correspondence Server boundary. All
transaction messages are replicated to 2 Correspondence Servers on one Campus and
1 on the other Campus. Thus all EFTPOS transaction messages can be deemed to be
secure at this point. Pathway’s policy is for this to be the primary point in the overall
Horizon solution for transaction security.
For EFTPOS, the next point for securing transactions should be within the MA’s
system. The Agent and Host layers may have secondary transaction security
requirements to enable end to end transaction security, however, the use of RDBMS
for transaction security reasons alone should be avoided if possible.
The threats to end-to-end integrity of the solution are:
e failure of any application or application interface in the route between the EFTPOS
Agent and MA
¢ failure of any individual hardware component in the route between the EFTPOS
Agent and MA
e failure of multiple hardware component in the route between the EFTPOS Agent
and MA (particularly whole Campus catastrophe)
[REQUIREMENT 23 - MANDATORY] Suppliers must from their experience
describe strategies for using their package regarding:
e end-to-end transaction integrity
¢ use of a dual campus strategy for resilience
¢ any backup facilities required for business data
e recovery from failure
5.2.4.3, Merchant Acquirer EFTPOS Service Timeout
If the time out period for authorisation to the Merchant Acquirer is exceeded then the
authorisation should be DECLINED
It is possible that Post Office Counters Ltd. may wish to introduce stand in
authorisation in the future.
[REQUIREMENT 24 - DESIRABLE] Suppliers must:
¢ confirm their support for stand-in authorisation
5.2.5 Security
5.2.5.1 MA Interface Security
It is expected that a secure interface will be required to each Merchant Acquirer.
[REQUIREMENT 25 - MANDATORY] Suppliers must:
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 28 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
e describe the security features of this interface and any administration functions
provided
5.2.5.2 Identification and Authentication
It is expected that only standard Windows NT user identification and authentication
functions will be employed.
[REQUIREMENT 26 - MANDATORY] Suppliers must:
e describe any other identification and authorisation functions used by their solution
© convey any NT configuration recommendations
5.2.5.3 Access Control
It is expected that only standard Windows NT access control functions will be
employed.
[REQUIREMENT 27 - MANDATORY] Suppliers must:
e describe any other access control functions used by their solution
© convey any NT configuration recommendations
5.2.5.4 Audit
The overall EFTPOS solution should include sufficient data to prevent the risk of ICL
Pathway being held accountable for the value of a transaction which is subsequently
queried by the MA or customer.
For example:
e the source (e.g. bank, MA, merchant) and type (e.g. normal, stand-in, telephone) of
authorisations must be discernible.
¢ proof of timely instantiation of hot card list updates must be possible to be used as
evidence to repudiate MA claims for rejected transactions.
[REQUIREMENT 28 - MANDATORY] Suppliers must:
e describe the audit features of their solution, including the storage and archiving of
transactions as part of the audit trail
5.2.5.5 Confidentiality and Integrity
It must not be possible for card numbers and expiry dates to be obtained by the casual
user. Usual retail practice should be followed here.
[REQUIREMENT 29 - MANDATORY] Suppliers must:
e describe any specific confidentiality and integrity features of their solution
e describe any specific functionality provided relating to the Data Protection Act
5.3 Interfaces
[REQUIREMENT 30 - MANDATORY] Suppliers are asked to:
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 29 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
e describe all external interfaces of their software required by the solution. Both
batch and on-line interfaces should be included as well as database access methods
available to access data directly e.g. to enable card parameter data to be replicated
in the counter systems.
identify if there are any security requirements e.g. digital signing for transactions
crossing their application interfaces
¢ provide published interface documentation with the tender response.
6. Standards
The supplier must confirm the conformance of their products in the following areas
and, if not currently conformant, the date when conformance will be achieved.
6.1 APACS Compliance
[REQUIREMENT 31 - MANDATORY] Suppliers must
© provide a compliance statement (preferably independent) for those standards
required by the solution viz. APACS 27/29, 29B, 30.
6.2 Year 2000 Compliance
The BSI definition of Year 2000 conformity is also attached. This defines that Year
2000 conformity shall mean that neither performance nor functionality is affected by
dates prior to, during and after the year 2000.
In particular:
e Rule 1. No value for current date will cause any interruption in operation.
© Rule 2. Date-based functionality must behave consistently for dates prior to,
during and after year 2000.
e Rule 3. In all interfaces and data storage, the century in any date must be
specified either explicitly or by unambiguous algorithms or inferencing rules.
© Rule 4. Year 2000 must be recognised as a leap year.
It is ICL’s policy to only purchase products which meet the ICL Year 2000
compliance criteria (based on the BSI conformity definition which is attached).
[REQUIREMENT 32 - MANDATORY] Suppliers must:
¢ complete the following ICL Year 2000 Questionnaire
© agree to certify compliance in due time
© comment on any other appropriate industry norms or standards relating to Year 200
compliance
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 30 of 39
ICL Pathway
Pathway EFTPOS Host Application -
Invitation to Tender
FUJ00117513
FUJ00117513
Ref: EF/DOC/001
Version: 1.0
Date: 10/11/97
ICL Year 2000 Questionnaire
Company:
Address:
Product:
Version:
Question
Do you have a Year 2000 compliance
policy and plan to achieve compliance?
What is the latest date that customer
support will be available?
Is the above product/version currently
Year 2000 compliant in terms if the
ICL/BSI criteria?
If Yes go to (3), if No go to (9)
How has this degree of compliance
been validated?
(e.g. were tests conducted with the
system clock set beyond 31.12.1999?)
Are validation schedules and results
available to ICL?
What is the furthest date supported in
the product?
Have any changes been made to any
interfaces to accommodate Year 2000?
If yes, is a statement available
describing them?
Is this statement provided with this
response?
Please explain why the product is not
compliant in terms of the ICL/BSI
criteria.
Do you intend to make the
product/version so compliant?
If yes, go to (12)
If not, which product/version will be so
compliant?
Itt1p0.doc
COMMERCIAL IN CONFIDENCE
Page 31 of 39
FUJ00117513
FUJ00117513
ICL Pathway — Pathway EFTPOS Host Application - Ref EF/DOC/001
Invitation to Tender Version: 1.0
Date: 10/11/97
Question Response
14 I Will you make your validation I YES/NO
plans/results/interfaces available?
13 I When will you make details of the
compliant version available?
15 I When will the compliant version be
available?
16 IIs the product protected by a date
related licence algorithm in its code?
18 I Is the above product directly dependent
upon another product for compliance?
If so please identify.
19 I If you have a Year 2000 product status
www page please provide address
details.
NAME? «2. ssanncessss: scmemae sss ranaanes Date: wissassssisssraaeme
Titles <5: seemeesess+seeeesemeass:+eeeeers
6.3 EMU Compliance
At this time, there are no UK standards for EMU compliance. To allow ICL Pathway
to assess the readiness of suppliers for this event we have produced the following
questionnaire:
© Does the software handle more than one currency?
e What are the storage implications of doing so?
e What are the processing implications?
e What is the impact of the six digit conversion requirement?
© Do you have a position statement or a roadmap?
¢ When will you be compliant?
¢ How will the change be implemented?
[REQUIREMENT 33 - DESIRABLE] Suppliers must:
© provide responses to the above questionnaire
7. Supporting Services
ICL Pathway will require a variety of services during development, implementation
and operation.
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 32 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
In their responses, suppliers must state the availability of services being proposed.
7.1 Documentation
[REQUIREMENT 34 - MANDATORY] Suppliers must:
provide details of any documentation required (own or 3“ party)
7.2 Installation Services
[REQUIREMENT 35 - MANDATORY] Suppliers must:
e provide details of their installation services and experience in their delivery
7.3 Customisation Services
[REQUIREMENT 36 - IMPORTANT] Suppliers must:
e provide details of their customisation services and experience in their delivery
e describe the configuration management approach employed
e describe the release method used
© test strategy for customised versions
e identify how customised versions are kept up to date e.g. using common source
code control
e identify the most common problems encountered and complaints received (plus
corrective action taken)
7.4 Consultancy Services
[REQUIREMENT 37 - MANDATORY] Suppliers must:
© provide details of their consultancy services and experience in their delivery
® propose what services they feel are appropriate to support the development,
integration and testing and Merchant Acquirer acceptance of the overall EFTPOS
service
e identify any testing tools or facilities available
7.5 Training Services
[REQUIREMENT 38 - MANDATORY] Suppliers must:
© provide details of any software training required for developers and testers and
experience in their delivery
e provide details of any software training required for operational staff and
experience in their delivery
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 33 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
7.6 Upgrades
[REQUIREMENT 39 - MANDATORY] Suppliers must:
¢ give details of their software update and new release roadmap for the next 3 years
e declare their policy on the backwards compatibility of new releases with old
versions of their product and old versions of NT and any other supporting software
e particularly, declare their strategy for keeping old releases compatible with new
releases of Windows NT , and their strategy for making future releases compatible
with old versions of Windows NT. The supplier must be willing to make
contractual commitments to the strategies declared
7.7 Support Services
[REQUIREMENT 40 - MANDATORY] Suppliers must:
e provide details of their help desk and error correction service
¢ indicate what service levels are available and recommend an appropriate level (see
later Warranty & Support section for required service levels)
e provide details of support guides provided
e describe the call management system employed
© confirm the availability of known error logs to customers
e state any policy on using customers’ own call management systems enabling
automatic call routing to the supplier
8. Implementation Plan
8.1 Business Priorities
Key Pathway implementation dates are identified in the timetable in Section 3.
8.2 Implementation Proposals
[REQUIREMENT 41 - MANDATORY] Suppliers must:
e describe how they propose to plan and control the implementation programme with
a particular emphasis on quality management and the role of ICL Pathway staff.
Any dependencies on ICL Pathway and other parties should be specifically defined
© propose plans for delivering and implementing their software
8.3 Sub-contracting
[REQUIREMENT 42 - MANDATORY] Suppliers must:
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 34 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
¢ provide details of any proposals to involve sub-contractors in the work.
9. Supplier Appraisal
9.1 Financial
[REQUIREMENT 43 - MANDATORY] Suppliers must:
© provide audited accounts for the last 2 years
© outline their strategic plans
e declare any legal actions outstanding
e declare any mergers, acquisitions pending
9.2 Implementation
[REQUIREMENT 44 - MANDATORY] Suppliers must:
¢ describe previous experience in providing similar software implementations
e demonstrate systems integration expertise
e provide a number of references of similar operational sites
© provide contact details for the responsible director (or equivalent) through whom
ICL Pathway can take up one or more of the references provided
9.3 Support
[REQUIREMENT 45 - MANDATORY] Suppliers must:
e declare their strategy for supporting old releases
e declare their strategy for supporting customer modifications
e identify the most common problems encountered and complaints received (plus
corrective action taken)
9.4 Package Stability
[REQUIREMENT 46 - MANDATORY] Suppliers must:
state the number of installed sites for products being offered
¢ the number of historical releases and timetable for future releases
© give an indication of company policy and plans for the future maintenance and
development of their software.
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 35 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
9.5 Service Assurance
In addition to the specific services identified above, we will be looking to build a long
term relationship with a supplier who is committed to a high quality customer service.
Accordingly ICL Pathway will favour those suppliers that hold BS EN ISO 9000
accreditation.
[REQUIREMENT 47 - MANDATORY] Suppliers must:
¢ complete the attached Vendor Evaluation (Quality Management System)
questionnaire
e identify a senior supplier manager to hold overall responsibility for the relationship
and to monitor progress and review performance on a regular basis
¢ state the level of BS EN ISO 9000 accreditation held
10. Commercial
10.1 Price Summary
[REQUIREMENT 48 - MANDATORY] Suppliers must:
e provide a one page summary showing all one off charges and annual recurring
charges.
10.2 Once Only Costs
[REQUIREMENT 49 - MANDATORY] Suppliers must:
¢ provide full details of all once only charges. Please differentiate between costs for
required items and any additional functionality or services proposed.
10.3 Recurring Costs
[REQUIREMENT 50 - MANDATORY] Suppliers must:
e provide full details of all recurring charges. Please differentiate between costs for
required items and any additional functionality or services proposed. It is a
mandatory requirement that support be available until 30/9/2005, and that any price
increases be capped, at a maximum in line with inflation. Suppliers should
propose a suitable price indexation formula.
10.4 Contract
[REQUIREMENT 51 - MANDATORY] Suppliers must:
e provide details of their terms and conditions for supply of software and services.
Suppliers must be willing to use these as the basis of negotiation.
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 36 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
10.5 Intellectual Property Rights
ICL Pathway does not require the Supplier to transfer ownership of IPR in its software
to ICL Pathway, however a conventional indemnity to cover potential breach of any
third party’s IPR must be given.
[REQUIREMENT 52 - MANDATORY] Suppliers must:
¢ Confirm their acceptance of this principle
10.6 Performance and Liability
Suppliers must be willing to accept financial penalties for late completion, measured
against the milestones shown in the “Timetable” section of this ITT. Failure to
achieve acceptance by the contractually agreed acceptance date shall render the
Supplier liable to liquidated damages at the rate of 2.5% of the contracted price per
week of delay. The maximum liability for breach of contract shall be the contract
value or £250,000, whichever is the greater.
[REQUIREMENT 53 - MANDATORY] Suppliers must:
© Confirm their acceptance of this principle
10.7 Warranty and Support
Suppliers must warrant that their software will conform to its specification for a
minimum of 12 months from the date of acceptance. Suppliers may offer a longer
warranty period, which will count in their favour in ICL Pathway’s evaluation.
[REQUIREMENT 54 - MANDATORY] Suppliers must:
e Confirm their acceptance of this principle, and declare any warranty duration
beyond 12 months that they wish to contract to.
Correction of errors, both under warranty and under any support agreement, must be
provided within defined timescales, depending on the seriousness of the fault. ICL
Pathway’s proposed matrix is as follows.
Action Category of Error
(a) (b) ©
Response 1 hour 1 hour 1 hour
Temporary Avoidance 4 hours 2 days 4 days
(2 hours for
category
(a) di)
Full Solution 2 days 4 days 7 days
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 37 of 39
ICL Pathway
FUJ00117513
FUJ00117513
Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: 1.0
Date: 10/11/97
Classification of Errors
Errors will be classified by ICL Pathway in one of the following categories:
(a)
(b)
(©)
Critical Errors (ICL Pathway Category A)
Errors which:
(i)
(ii)
(iii)
(iv)
prevent a service of or for ICL Pathway or an ICL Pathway customer
being run so as to endanger the business of ICL Pathway or an ICL
Pathway customer; and/or
prevent a time-critical task being undertaken by ICL Pathway or an ICL
Pathway customer; and/or
cause, or have caused, the corruption of ICL Pathway’s or an ICL
Pathway customer’s data; and/or
are not covered by (a)(i)-(iii) above but which in the reasonable
opinion of ICL Pathway are critical.
Major Errors (ICL Pathway Category B)
Errors which:
a)
(i)
(iii)
(iv)
cause severe degradation to the Software; and/or
place risk on the operation of an important task by ICL Pathway or an
ICL Pathway customer; and/or
cause any other situation or problem requiring urgent resolution; and/or
are not covered by (b)(i)-(iii) above but which in the reasonable
opinion of ICL Pathway are major.
Minor Errors (ICL Pathway Category C)
Errors which:
(i)
(ii)
(iii)
(iv)
cause minor problems or inconvenience in the Software; and/or
prevent a non-time critical task being completed; and/or
arise as a result of the deficiency of the Software's documentation;
and/or
are not covered by (a), (b) or (c)(i)-(iii) above.
If and until Pathway classifies any particular error, the Supplier shall use its own
reasonable judgement in making the appropriate classification.
Classification of Actions
Itt1p0.doc
COMMERCIAL IN CONFIDENCE Page 38 of 39
FUJ00117513
FUJ00117513
ICL Pathway Pathway EFTPOS Host Application - Ref: EF/DOC/001
Invitation to Tender Version: ton 91
“Response” means the time from initial receipt of an error in which the Supplier shall
provide an initial response to ICL Pathway and report the path for resolution of the
error.
“Temporary Avoidance” means the time from initial receipt of an error in which the
Supplier will respond with an interim solution while working on a full solution.
“Full Solution” means the time from initial receipt of an error in which the Supplier
shall provide the following as appropriate:
source code clearance
e revised issue of source code
¢ machine readable object code copy of the source code clearance and revised source
code;
¢ documentation changes;
e proof that the correction has been successfully tested and implemented into the
source code.
[REQUIREMENT 55 - MANDATORY] Suppliers must:
¢ Confirm their acceptance of this principle, and their agreement to the matrix shown
above; Suppliers may at their discretion propose alternative values for the matrix,
which will be taken into consideration in ICL Pathway’s evaluation.
10.8 ESCROW
ICL Pathway requires that the suppler must deposit a copy of the source code and
related documentation in escrow, with the NCC, under the standard NCC escrow
contract.
[REQUIREMENT 56 - MANDATORY] Suppliers must:
confirm their agreement to this
Ittlp0.doc COMMERCIAL IN CONFIDENCE Page 39 of 39