FUJ00001419
FUJ00001419
ICL Pathway Service Architecture Design Document Ref: CR/FSP/004
POCL Service Architecture Version: 6.0
Date: 23/10/00
2. SERVICE ARCHITECTURE
2.1 SERVICE INFORMATION FLOWS
Figure 2-1 shows the Pathway-centric view of the information flows
between Pathway and entities external to Pathway.
POCL Client
rn OCI Clients
ESNCS. Stop, Recall Inout
Notices & Payment
Reports APData
Reference
Data
Teansaction Data
] Summaries
Reference Data Orders,
Remittances, Stock ¢
Declarations H
Post Office
AP, OBCS,
EPOSS, LFS
Interactions
Counter Interaction:
Customers Counter Saft f=
Figure 2-1: Pathway Service information flows
The dotted lines represent significant information flows that are outside
of the Horizon system.
Many of the information flows are program-based, but some are paper-
or voice-based. For example:
e Acustomer paying a bill is served at the counter. The Pathway AP
and TPS service will effect the logical completion of the information
flow by notifying both the POCL client and the POCL transaction
accounting system TIP.
e Acustomer collecting his benefit by way of a bar-coded order book
will be able to do so because the book is not present on the stop list
that ICL Pathway has constructed from information supplied by
ESNCS and has made visible to the OBCS application. Pathway
will subsequently complete the end-to-end flow by notifying ESNCS
© 2000 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Printed: 10/24/00
C:\__All\_SADD\Sadd60W6\S602 (Service Arch).doc
Page 6
ICL Pathway
FUJ00001419
FUJ00001419
Service Architecture Design Document Ref: CRIFSP/004
POCL Service Architecture Version: 6.0
Date: 23/10/00
2.2
of the amount paid and notifying TIP that the post office made the
payment.
e A post master may encounter a counter equipment failure and will
speak on the telephone to the Pathway Horizon System Help Desk
(HSHD). The HSHD will complete the logical information flow by
arranging for an engineer to attend and rectify the fault.
PATHWAY SERVICE COMPONENT RELATIONSHIPS
Figure 2-2 shows how the total Pathway service is divided into its
major service elements and the relationships between them, and the
program-based entities within POCL.
It also illustrates how the principal program information flows referred
to above are mapped between the service elements. For example:
e The stop list flow starts at ESNCS. OBCS Host transfers stop list
entries to TMS, which thus become visible to OBCS Counter. Ifa
customer book is not stop-listed the OBCS Counter controls the
payment process and records the transaction within TMS. OBCS
Host will notify ESNCS of the amount paid and the post office
accounting routines within EPOSS will notify POCL’s TIP system of
the transaction.
¢ The bill payment flow proceeds from the APS or EPOSS service to
the recipient POCL client. The post office accounting routines
within EPOSS will notify POCL’s TIP system of the transaction.
© 2000 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Printed: 10/24/00
C:\_All\_SADD\Sadd60W6\S602 (Service Arch).doc
Page 7
FUJ00001419
FUJ00001419
ICL Pathway Service Architecture Design Document Ref: CR/FSP/004
POCL Service Architecture Version: 6.0
Date: 23/10/00
t ea r
v y
{ y VY y
4 ry a a a
v v v v
y Y
Figure 2-2: Pathway major service component relationships
[REMOVED]
2.4 BUSINESS CONTINUITY
2.4.1 CONTINGENCY
[R830]
Pathway has developed the contingency arrangements that are used
to ensure continuity of service, as described in R830 and as defined in
Section 4.1.6, POCL Contingency Services.
Pathway has defined detailed contingency plans developed from jointly
developed impact and risk assessments. They describe the
contingency actions and their time-tabling and set standards for testing
including regression testing. See Business Continuity Framework and
subsidiary references.
2.4.2 PATHWAY BUSINESS CONTINUITY
Pathway has developed and implemented procedures to ensure
© 2000 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Printed: 10/24/00
C:\_All\_SADD\Sadd60W6\S602 (Service Arch).doc
Page 8
ICL Pathway
FUJ00001419
FUJ00001419
Service Architecture Design Document Ref: CRIFSP/004
POCL Service Architecture Version: 6.0
Date: 23/10/00
2.5
2.5.1
2.5.2
continuity of its own operation, see Business Continuity Framework.
SECURITY INFRASTRUCTURE
INTRODUCTION
[R698]
Pathway has established a security infrastructure that minimises and
controls liabilities to itself and POCL as specified in R698. The
Pathway Security Policy is described in /CL Pathway Security Policy
and the corresponding procedures in Security Management
Procedures. Issues relating to data confidentiality, integrity and
access control are described in the Security Functional Specification
and Access Control Policy.
FRAUD RISK MANAGEMENT
[R698, R829, R832, R895]
The management of fraud risk within the Service Architecture is
described in ICL Pathway Security Policy and in Security Management
Procedures. Fraud risk may also be managed through the provision of
Management Information System (MIS) reports. In addition, a fraud
monitoring system, to profile certain irregular encashment patterns and
identify potential fraud incidents is provided, see below
Pathway’s policy is to identify and minimise the risk of fraud within the
Pathway system. However, Pathway recognises that the threat of fraud
incidents exists inside and outside Pathway’s responsibility.
Of particular concern is the specification of procedures followed by
POCL staff in an outlet automated with Horizon. Agreed procedures
associated with the Horizon automated system are documented in
Processes & Procedures Descriptions including CSR+ Logistics
Feeder Service: Processes And Procedures Description.
Pathway’s strategy is to identify high risk situations and adapt systems
as necessary to:
e Minimise fraud exposure within the Pathway solution
e Provide information service to POCL to aid fraud investigation and
to minimise fraud
The information provided is:
e Information to aid in the investigation of actual fraud incidents
© 2000 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Printed: 10/24/00
C:\_All\_SADD
\\Sadd60W6\S602 (Service Arch).doc
Page 9
ICL Pathway
FUJ00001419
FUJ00001419
Service Architecture Design Document Ref: CRIFSP/004
POCL Service Architecture Version: 6.0
Date: 23/10/00
¢ Certification relevant to operation of the system as required by
Police & Criminal Evidence (PACE) Act, 1984 and equivalent
legislation as required by the territory of operation (R829).
e Information for the investigation of system boundary related
incidents and trends; for example, counter staff-related fraud with
the aim of developing improved procedures
e Analysis of incidents and trends within Pathway’s immediate control,
to improve its systems
2.5.2.1 MANAGEMENT INFORMATION SYSTEM REPORTS
[R837, R894, R914]
The standard MIS reports are defined in POCL MIS Reports
[DN: This document is intentionally empty.]
Ad hoc reports are available for EPOSS and the HSHD.
2.5.2.2 IRREGULAR ENCASHMENT PATTERNS
[R895]
The Service Architecture is capable of monitoring and reporting
irregular encashments.
Information is shared with POCL Audit/Security/Operations when it
relates to a post office.
Daily reports are provided of transactions at outlets that have been
notified to Pathway as temporarily out of commission, that is temporary
and emergency closures.
2.6 DATA PROTECTION ACT
[R938]
Pathway is responsible for ensuring that any information supplied
under the Data Protection Act is accurate and that assurances can be
given as to the integrity of that information.
Pathway is responsible for delivering any information requested under
the Data Protection Act to the requesting body, or person as
appropriate.
The Data Protection Act 1984 came into effect on 11 November 1987
and the Data Protection Act 1998 on 24 October 1998. Pathway
ensures that all subsequent alterations and reviews to this law are
integrated and adhered to.
© 2000 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Printed: 10/24/00
C:\_All\_SADD\Sadd60W6\S602 (Service Arch).doc
Page 10
ICL Pathway
FUJ00001419
FUJ00001419
Service Architecture Design Document Ref: CRIFSP/004
POCL Service Architecture Version: 6.0
Date: 23/10/00
2.7
Pathway records all written requests for a data protection print from a
customer or representative within five (5) days of receipt of the request
in respect of data held on behalf of POCL.
All information provided under the Act is made available to facilitate
inspection.
Details of a request and response made under the Act will be retained
consistent with the Act’s requirements.
OPERATIONAL AUDIT
[R472, R697, R699, R829]
The POCL Service Architecture provides for audit of its operation by
auditors accredited by POCL and POCL’s commercial Clients. The
composition of the audit trail and its arrangement into audit tracks,
appropriate to the roles and access rights of individual auditors, and
the maintenance of, and access to, these tracks is described in Audit
Trail Functional Specification.
The systematic controls inherent in the Pathway solution are described
in Solution & Service Reconciliation.
© 2000 ICL Pathway Ltd COMMERCIAL-IN-CONFIDENCE Printed: 10/24/00
C:\_All\_SADD\Sadd60W6\S602 (Service Arch).doc
Page 11