FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
Document Title: Network Banking Reconciliation & Incident Management
Document Type: Procedure
Release: N/A
Abstract: This document outlines the end-to-end reconciliation and
incident management procedures required to investigate, report
and resolve Network Banking reconciliation and business
incidents.
Document Status: APPROVED
Originator & Dept: Richard Brunskill (MSU Manager, ICL Pathway)
Contributors: ICL Pathway: Michael King, Dina Chauhan, Nathan Monk,
Angela Shaw
Reviewed By: ICL Pathway: Angela Shaw, Michael King, Dina Chauhan, Mik
Peach, Paul Westfield, David Hollingsworth, Tony Hayward
PON: Glenys Latham, Ijaz Bhatti, Claire Bennett, Jayne
Widdowson, Sharon Holness, Alan Orpe, Marian Dale, Jeanette
Brown
Comments By:
Comments To:
Distribution: ICL Pathway Document Management
Reviewers
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 1 of I
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
1.0
COMMERCIAL IN CONFIDENCE 19/12/01
0.0 Document Control
0.1 Document History
Version No. I Date Reason for Issue Associated
CP/PinICL
0.1 22/10/01 Initial Draft N/A
1.0 19/12/01 Second draft following internal and POL review I N/A
0.2 Approval Authorities
Name Position Signature Date
Paul Westfield ICL Pathway
Infrastructure Services
Manager
Jeanette Brown Business Design - POL
0.3. Associated Documents
Reference Version I Date Title Source
1. CS/SPE/011 1.0 19/12/01 Network Banking End to PVCS
End Reconciliation
Reporting
2. NB/SDS/004 System Design Specification I PVCS
for Network Banking
3. CR/SPE/028 Network Banking PVCS
Transaction States and Data
Flows
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 2 of 1
ICL Pathway
Ltd
Network Banking Reconciliation & Incident Ref: Nl
Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
0.4 Abbreviations/Definitions
Abbreviation
Definition
Business Incident
Any exception (as defined below) reported via NB102 or via the
HSH requiring investigation and the provision of corrective
information to allow POL to settle or reconcile. A Business Incident
relates to the ‘Symptom’ and not to the root cause of the exception.
Exception Types Within all reports the ‘Exceptions’ category will include:
e ‘Incomplete States’, i.e. those transactions where one or more
transaction component is missing — a C4 without a C12 ete
e Genuine exceptions where transaction components belonging to
the same high level transaction have been exceptioned, i.e. C12
(amount) not = to C4 (amount) etc.
e NBE/ DRS corruption’s
MSU Day Between 08.00hrs and 17.30hrs Monday — Friday inclusive,
excluding English bank holidays
System Incident
Any exception (as defined above) reported via NB102 or via the
HSH requiring the investigation and repair of the root cause of the
exception.
APS Automated Payment Service
BIMS Business Incident Management Service
BSM Business Service Management ( AP Service Provision Team — PON)
DRS Data Reconciliation Service
EPOSS Electronic Point of Sale Service
HSH Horizon Systems Helpdesk
MER Manual Error Report
MSU Management Support Unit
NBE Network Banking Engine
NWB Network Banking
POL Post Office Limited
SIL System Incident Log
SSC System Support Centre
TIP Transaction Information Processing
TP Transaction Processing
TPS Transaction Processing Service
0.5 Changes in this Version
© 2001 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Page 3 of I
FUJ00120466
FUJ00120466
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: Nl
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
Version Changes
0.2 e New section ‘Disputed transactions’ included
e Report definitions amended to be consistent with CS/SPE/011
© Process maps amended following discussion
¢ Definition of SLA components included in detail
e Re- structuring of document following POL review
0.6 Changes Expected
Changes
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 4 of 1
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
0.7 Table of Contents
1.0 INTRODUCTION...
2.0 SCOPE....
3.0 NWB RECONCILIATION REPORTS....
3.1 REPORTS PRODUCED BY ICL PATHWAY CENTRAL SY’ M) 9
NB100a: NBE / DRS Reconciliation Statement. 9
NB100b — TIP DRS Reconciliation Statement. 10
NB101a — Network Banking Settlement Statement <= 5 days.
NB101b — Network Banking Settlement Statement > 5 days..
NB102 - Exception Summary...
3.1. NB103 — Settled Transaction / Cash Account Reconciliation Statemen
3.2. REPORT DISTRIBUTION & CHECKING......... os
3.2.1 Contingency in the Event on Non delivery ‘of reports I to PON....
4.0 RECONCILIATION & INCIDENT HANDLING........
4.1 INCIDENT CLASSIFICATION
4.1.1 NWB Business Incidents.
4.1.1.1 NWB Reconciliation Repo
4.1.2. System Incidents...
4.2 NWB BUSINESS INCIDENT ORIGINATOR:
4.3. GENERATION OF BUSINESS INCIDENTS...
4.3.1 Business Incidents Raised via the HSH by ICL Pathway 7 MSU.
4.3.2 Business Incidents Raised via the HSH by POL..
4.3.3 Disputed Transactions Raised via the Enquiry Service.
4.4. NWB INCIDENT REPORTING...........00:000
4.4.1 _ BIMS Reports / MER... sess see esse 7
4.4.1.1 Format & content of BIMS report /} MER...... . ce 21
4.4.1.2 Clearance & Closure Criteria., .
4.4.1.3 BIMS Report Distribution
4.4.2 System Incident Log..
4.4.3 NWB Exception Resolution Timescales..
4.4.3.1 I NWB Business Incident SLA conditions......
4.4.3.2 NWB System Incident Resolution Timescale:
4.4.4 Widespread Errors.
4.4.5 Repairing Data....
5.0 NWB BIMS REPORT.....
6.0 INCOMPLETE AND EXCEPTION STATE
6.1 INCOMPLETE STATES.
6.2 EXCEPTION STATES.
7.0 INCIDENT MANAGEMENT PROCESS FLOWS.
7.1 INCOMPLETE & EXCEPTION STATE PROCESS MATRIX. 29
7.2 MSU NETWORK BANKING Top LEVEL.......
7.3 RECONCILIATION REPORT PRODUCTION AND. ‘CHECKING PROCESS — LEVEL 1
7.4. RECONCILIATION REPORT ANALYSIS — LEVEL 2...
7.5 ENQUIRY SERVICE PROCESS — LEVEL 1...
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 5 of I
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
7.6 ENQUIRY SERVICE — INVESTIGATE — LEVEL 2
7.7 BIMS PROcESS — LEVEL I
7.8 BIMS PROCESS — LEVEL
7.9 PROCESS AA — LOCATION OF MISSING C4, S OR D TRANSACTION COMPONENT.
7.10 PROCESS BB — LOCATION OF MISSING C112 TRANSACTION COMPONENT
7.11 PROCESS CC — LOCATION OF MISSING C12 TRANSACTION COMPONEN
7.12 PROCESS DD - CUSTOMER ENQUIRY AND INVESTIGATION OF D TRANSACTION
COMPONENT EXCEPTIONS. 41
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 6 of 1
ICL
Ltd
FUJ00120466
FUJ00120466
Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
1.0 Introduction
The Network Banking (NWB) report set produced by ICL Pathway central systems
has been designed to enable NWB transactions completed in the outlets to be
reconciled to the outlet Cash Account and settlement to be made with Post Office
Limited (POL) clients, e.g. Link, or direct settlement to specific clients.
ICL Pathway central systems will produce a suite of reports in accordance with the
rules documented within ‘CS/SPE/011; Network Banking End to End Reconciliation
Reporting’, which reconcile all the individual transaction components making a NWB
transaction. Reconciliation is essentially at two levels, the counter reconciling with the
‘Client’ and the counter reconciling with POL central systems — the Cash Account.
In addition to those exceptions reported by ICL Pathway within the NWB report set,
reconciliation errors may be discovered by POL when reconciling data within it’s
central systems or relating to queries from POL clients. To initiate the Business
Incident Management Service (BIMS) process, ICL Pathway or POL Transaction
Processing (TP) or Business Service Management (BSM) generates NWB Business
Incidents for one or more exceptions or reconciliation errors discovered.
The incident management process is generic for all services. Electronic Point of Sale
Service (EPOSS), Automated Payment Service (APS) and NWB incidents are raised,
documented and progressed to resolution in the same manner. It should be noted
however, that where a NWB incident DOES NOT affect reconciliation within POL
Transaction Information Processing (TIP), the provisions quoted within the Codified
Agreement (CA) schedule G01, in respect of charges levied for Manual Error Reports
(MER), DO NOT apply. Definition and charges for NWB / Transaction Processing
Service (TPS) related errors, subject to the provisions of CA schedule G01, where the
incident has caused a reconciliation or settlement error within TIP are found in
associated ICL Pathway document: ‘CS/PRO/I11: TPS Reconciliation & Incident
Management’
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 7 of I
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
2.0 Scope
This document sets out the reconciliation and incident management procedures to be
adopted by ICL Pathway / Management Support Unit (MSU) for dealing with NWB
reconciliation report distribution to POL and any associated NWB Business Incidents
which may arise, including:
e NWB reconciliation report exceptions and incomplete states
¢ Software faults affecting reconciliation and settlement
e POL client enquiries / disputed transactions
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 8 of I
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd
Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
3.0 NWB Reconciliation Reports
3.1. Reports produced by ICL Pathway central systems
3.1.1
NB100a: NBE / DRS Reconciliation Statement
This report reconciles the Network Banking Engine (NBE) with the Data
Reconciliation Service (DRS) output from the outlet.
1.
NBE / DRS exceptions outstanding from previous days — This figure identifies
NWB NBE/ DRS exceptions that were not cleared from the previous day..
NBE / DRS exceptions manually cleared — This figure identifies NWB NBE /
DRS exceptions that were cleared by MSU (F99), the previous day.
Sub total of lines 1 & 2
NBE / DRS corruption’s outstanding from previous days — This figure
identifies NWB NBE / DRS corruption’s that were not cleared from the previous
day.
NBE / DRS corruption’s manually cleared — This figure identifies NWB NBE /
DRS corruption’s that were cleared by MSU (F99), the previous day.
Sub total of lines 4 & 5.
7. CCT processed today — This figures identifies all successfully confirmed client
10
14
transactions processed today (C4)
ACTAC Processed today — This figure identifies all authorised client transactions
processed today which have not yet been matched to a counter confirmation (S)
ECT processed today — This figure identifies all reconciliation differences
highlighted within the NBE processed today (D).
. Sub total of lines 7,8 & 9
ll.
Counter confirmations processed today — This figure identifies all counter
confirmation transactions processed today (C12)
.CCT / Counter confirmations matched today — This figure identifies all
successfully confirmed client transactions (C4) that have been matched with
counter confirmation transactions today (C12)
. NBE / DRS exceptions outstanding today — This figure identifies NWB NBE /
DRS exceptions that are uncleared at the end of this day.
NBE / DRS corruption’s outstanding today — This figure identifies NWB NBE /
DRS corruption’s that are uncleared at the end of this day.
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 9 of 1
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
3.1.2
NB100b — TIP DRS Reconciliation Statement
This report reconciles POL TIP with the DRS output from the outlet.
1.
wn
TIP / DRS exceptions outstanding from previous days — This figure identifies
NWB TIP / DRS exceptions that were not cleared from the previous day.
TIP / DRS exceptions manually cleared — This figure identifies NWB TIP / DRS
exceptions that were cleared by MSU (F99), the previous day.
Sub total of lines 1 & 2
Counter confirmations received today — This figure identifies all counter
confirmation transactions processed today (C12)
TIP transactions received today — This figure identifies all NWB EPOSS
transactions forwarded to TIP and posted to the Cash Account today(C112)
Sun total of lines 4 & 5
7. Counter confirmations / TIP transactions matched today — This figure
identifies all counter confirmations (C12) that have been matched to TIP
transactions (C112) today
TIP / DRS exceptions outstanding today — This figure identifies NWB TIP /
DRS exceptions that are uncleared at the end of this day
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 10 of 1
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
3.1.3 NB101a — Network Banking Settlement Statement <= 5 days
This report provides settlement information based upon the ‘Client View’ where
transaction components have been received by the DRS less than or equal to five days
after the reconciliation date.
1. Confirmed transactions — This figure identifies all successfully confirmed client
transactions (C4), with a reconciliation date applicable to the date of the report
column.
2. Late confirmed transactions — This figure identifies all successfully confirmed
client transactions (C4), that have been received by the DRS on the run date of the
report where the run date of the report is later than the reconciliation date
applicable to the date of the report column.
Sub Total of lines 1 & 2
Unconfirmed transactions — This figure identifies all authorised client
transactions (S), that have not yet matched to a counter confirmation (C12), with a
reconciliation date applicable to the date of the report column
5. Late unconfirmed transactions — This figure identifies all authorised client
transactions (S), that have not yet matched to a counter confirmation (C12), that
have been received by the DRS on the run date of the report, where the run date of
the report is later than the reconciliation date applicable to the date of the report
column.
6. Sub Total of lines 4 & 5
7. Total of confirmed and unconfirmed transactions — Total of lines 3 & 6
8. Exceptioned transactions — This figure identifies all reconciliation differences
highlighted within the NBE (D), with a reconciliation date applicable to the date of
the report column.
9. Late exceptioned transactions — This figure identifies all reconciliation
differences highlighted within the NBE (D), that have been received by the DRS on
the run date of the report, where the run date of the report is later than the
reconciliation date applicable to the date of the report column.
10. Total of confirmed, unconfirmed and exceptioned transactions — Total of lines
7,8&9
11. NBE / DRS exceptions O/S — This figure identifies all NWB NBE / DRS
exceptions that are uncleared at the end of this day.
12. TIP / DRS exceptions O/S — This figure identifies all NWB TIP / DRS exceptions
that are uncleared at the end of this day.
13. NBE / DRS corruptions O/S — This figure identifies all NWB NBE / DRS
corruption’s that are uncleared at the end of this day.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 11 of I
ICL
Ltd
FUJ00120466
FUJ00120466
Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
3.1.4
NB101b — Network Banking Settlement Statement > 5 days
This report provides settlement information based upon the ‘Client View’ where
transaction components have been received by the DRS more than five days after the
reconciliation date.
Report NB101b report layout follows report NB101a. However it commences on
Reconciliation Date / Column Date = Today — N where N >= 5. There is no maximum
number of days within report NB101b. NB101b reports as many Reconciliation Dates /
Column Dates as necessary subject to the rules identified within section 3.1.4.1 of
“‘CS/SPE/011: Network Banking End to End Reconciliation Reporting’. For example,
if on 06/01/01, subject to the rules identified within section 3.1.3.1 of ‘CS/SPE/011:
Network Banking End to End Reconciliation Reporting’ for NB10la, either an
exception remains or a new transaction is received for Reconciliation date 01/01/01 or
earlier, the appropriate Reconciliation Date / Column Date would be included within
NB101b until no exceptions remained. In effect, NB101b could run for an indefinite
number of Reconciliation Dates / Column Dates if exceptions remained or later
transaction components were received.
© 2001
ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 12 of 1
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
3.1.5 NB102 — Exception Summary
The report identifies all incomplete or exception states.
This report is divided into 12 sections:
Section 1: Uncleared confirmed, unconfirmed and TIP exceptions <24 hrs
e Reports exceptions by ‘Incomplete or Exception System State’ and reconciliation
date. Where no exceptions are reported for a particular system state, the row is
suppressed.
Section 2: Uncleared exceptioned client transactions
e Reports NBE exceptions, (D), individually listed in system state order and
reconciliation date where the incomplete or exception state suggests an urgent
resolution is required to avoid customer dissatisfaction
Section 3: I Uncleared NBE / DRS corruption’s
e Reports NBE / DRS corruption’s individually listed in system state order and
reconciliation date.
Section 4: Uncleared timing differences
e Reports transaction components where there is a difference in the reconciliation
date and the posting date allocated where an ‘S’ has been received with an earlier
or later date than the ‘C4’. The ‘C4’ automatically assumes the ‘S’ reconciliation
date however the transaction is exceptioned.
Section 5: Uncleared confirmed, unconfirmed and TIP exceptions >24 hrs
e Reports defined uncleared exceptions (see CS/SPE/011) previously included within
Section 1 which have remained uncleared for a period of greater than 24 hours.
They are removed from section I and listed individually in system state and
reconciliation date order.
Section 6: Uncleared future dated settlement transactions
e Reports any transactions received by the DRS from the NBE which are ‘future
dated’ — Settlement date > report run date +3 in system state and reconciliation
date order.
Section 7: Cleared confirmed, unconfirmed and TIP exceptions <24 hrs
e As section 1 — exceptions cleared and set to ‘F99’ by ICL Pathway MSU
Section 8: Cleared exceptioned client transactions
e As section 2 — exceptions cleared and set to ‘F99’ by ICL Pathway MSU
Section 9: Cleared NBE / DRS corruption’s
e As section 3— exceptions cleared and set to ‘F99’ by ICL Pathway MSU
Section 10: Cleared timing differences
e As section 4 — exceptions cleared and set to ‘F99’ by ICL Pathway MSU
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 13 of I
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
Section 11: Cleared confirmed, unconfirmed and TIP exceptions >24 hrs
e As section 5 — exceptions cleared and set to ‘F99’ by ICL Pathway MSU
Section 12: Cleared future dated settlement transactions
e As section 6 — exceptions cleared and set to ‘F99’ by ICL Pathway MSU
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 14 of I
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
3.1.6 NB103 - Settled Transaction / Cash Account Reconciliation
Statement
This report allows POL to reconcile the settlement stream against the outlet Cash
Account stream. This reconciliation is required as settlement with the individual POL
clients is based upon the reconciliation date, i.e. the business day upon which the
transaction took place — this is carried right through the ‘C4’, ‘S’, & ‘D’ transaction
components. To complete a full reconciliation, it is important to know which Cash
Account the settled transaction was posted to, in order to enable a reconciliation of
settlement to be made with the outlet records. This report reconciles the transactions
by reconciliation date and Cash Account record.
1.
NB103 is run weekly: In order to align with internal POL / TIP processing it is
required that this report is produced AFTER TPS processing on Friday and
BEFORE TPS processing on Saturday. The report will include all C4, S and D
transaction components where:
¢ reconciliation date = run date and,
e reconciliation date = run date — ‘N’ (where ‘N’ = I to 13).
Where a C112 is available and the CAP is known, the transaction will be posted
against the appropriate CBDB applicable to the reconciliation date — (see rules 6 &
7)
Where no C112 is available and therefore the CAP is unknown:
e the C4, S and D transaction components will be posted to ‘No Cash Account
Allocated’ (Column 7
e then, when the C112 becomes available, the entry will be deleted from ‘No
Cash Account Allocated’ (Column 7) and posted to the appropriate CBDB
week applicable to the reconciliation date on the C112 (see rules 6 & 7)
e ifno C112 has been received after 14 days, the entry within ‘No Cash
Account Allocated’ (Column 7) will remain until the C112 becomes
available even if this exceeds 14 days
If a transaction is posted to the row ‘No C/A to TIP’ (according to it’s
reconciliation date):
¢ the transaction will remain in this row until the Cash Account has been
delivered to TIP and then move up into the row ‘C/A to TIP’
e ifno Cash Account has been delivered to TIP after 14 days, the entry within
‘No C/A to TIP’ should will until the Cash Account is delivered to TIP
even if this exceeds 14 days
As the report is run each week, the transactions will move across the report
according to the CAP and the reconciliation date; for example, a transaction where
the Cash Account has been delivered to TIP and posted to CBDB>=plus 2 in the
first week, will move to CBDB plus I the second week and then appear in CBDB
the third week, until disappearing off the report after 14 days
This report identifies VALUE only against five Cash Account Periods (CAP’s).
Those CAP’s equate to the Counters Business Database (CBDB) date, the CBDB
date minus 1, the CBDB date <=minus2, the CBDB date plus 1 and the CBDB
date >= plus 2. In addition, those settled transactions, which currently have not
been allocated a relevant CAP, will also be identified.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 15 of 1
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
7. The CBDB CAP equates to TWO CAP’s prior to the CAP applicable to the run
date of the report. For example; if the report was run on Saturday 20" January
within CAP42 (CAP 42 commenced on Thursday 17" January), the CBDB CAP
would be CAP40 (CAP 40 commenced on Thursday 3" January, ended
Wednesday 9" January).
8. Where the CAP in which the outlet is trading is numerically more than 2 weeks
prior to the CBDB CAP, if this takes the outlet CAP into the previous year, this
will be reported as such. For example; the CBDB CAP is CAP I and the outlet is
trading in CAP 51, this is assumed to be CAPS1 of the previous year, (therefore
CBDB <=minus2) and not reported ahead in the current year.
© 2001 ICL Pathway Ltd. = COMMERCIAL IN CONFIDENCE Page 16 of 1
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
3.2. Report Distribution & Checking
Both daily and weekly reports will be available by 08.00hrs the day following the run
date of the report to:
e POL/ TIP gateway: The Host writes the reports to an appropriate directory. These
are picked up by FTMS and posted to the TIP gateway. (As per other Host to
external system applications)
e ICL Pathway CS/MSU DRS Workstation - MSU will check each report for
mathematical accuracy only.
All reports will be produced as ASCII text files — one for each report. The report
layout will be fixed format with space characters providing the blank space. This will
allow for ‘Excel’ input, using fixed field width facilities. Any formatting, (lines and
shading) will not be included within the file
3.2.1 Contingency in the Event on Non delivery of reports to PON
If ICL Pathway are unable to deliver all or any individual report to the POL / TIP
gateway by 08.00hrs the day following the run date of the report, ICL Pathway MSU
Manager will liase with the Incident Manager POL / TP to arrange an e mail
transmission via the ICL Pathway account within the POL corporate mail system of
reports NB101a and NB101b only. ICL Pathway / MSU will operate this contingency
under ‘reasonable endeavours’ and will aim to have the reports with POL by 08.00hrs.
However this timescale may not be achievable if processing problems have also
delayed receipt of the reports into the DRS workstation. Should the POL corporate
mail system be unavailable to ICL Pathway, then ICL Corporate mail is used as an
alternative.
NB: Should the corporate e mail service of either organisation be unavailable, the
Manager ICL Pathway /MSU will liase with the Manager POL / TP and agree
facsimile of reports NB101a and NB101b only.
Any distribution list for these reports is considered by both ICL Pathway and POL to
be of a dynamic nature and therefore specific addressees are not covered within this
document.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 17 of I
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
4.0 Reconciliation & Incident Handling
4.1 Incident Classification
4.1.1 NWB Business Incidents
Business Incidents relate to the ‘Symptom’ of an underlying cause — e.g. the effect of
the system fault on the resulting reconciliation or settlement information sent to POL.
A NWB Business Incident relates to one or more of the exceptions reported within the
NWB Report Set, or one or more reconciliation or settlement errors / disputed
transactions raised in accordance with this document by POL / TP / BSM. (Refer to
section 6.0 for a list of those NWB Business Incident incomplete or exception states
currently known and for which appropriate NWB Business Incident reporting
processes are set out in this document).
4.1.1.1 NWB Reconciliation Report Exceptions
Exceptions reported within the NWB reconciliation report set will be applicable to:
Communication difficulties between the outlet and the Campus
Communication difficulties between the Campus and the NBE
Errors within the NBE
Errors within the DRS
Errors causing TIP transactions not be harvested
Corruption’s within the NBE / DRS
eeoeeee
4.1.2 System Incidents
System Incidents Relate to the underlying ‘Cause’
Following the creation of a NWB Business Incident, ICL Pathway may raise an
associated System Incident to identify and repair the underlying cause of a NWB
Business Incident. System Incidents will be routed to the appropriate group within ICL
Pathway, for investigation and resolution.
Where there are associated System Incidents and NWB Business Incidents, their
relationship can be either:
one to one; or
© one to many, respectively.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 18 of I
ICL
Ltd
FUJ00120466
FUJ00120466
Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
4.2
4.3
4.3.1
4.3.2
NWB Business Incident Originators
Generation of Business Incidents
In line with the generic incident management policy agreed between ICL Pathway and
POL, NWB Business Incidents will only be recognised as such if generated by ICL
Pathway or POL as appropriate, via the HSH or via the ‘Enquiry Service’. This
ensures that the NWB Business Incident is properly logged, enabling ICL Pathway /
MSU to ensure that corrective information can be supplied and any underlying system
fault can be rectified.
It is envisaged that NWB Business Incidents will only be generated by the following
groups within ICL Pathway and POL:
e ICL Pathway / MSU for exceptions reported via the NWB Report Set
e POL TP / BSM for any other reconciliation / settlement error or disputed
transaction discovered by POL that has not been reported by ICL Pathway via the
NWB report set
e ICL Pathway / System Support Centre (SSC) for any system fault or data ‘surgery’
which is considered by ICL Pathway to have a reconciliation or settlement
implication within POL in respect of NWB transactions.
Subject to agreement by the parties to the contrary, Post Office outlet calls to the
Horizon System Helpdesk (HSH) will not generate NWB Business Incidents. However
calls from Post Office outlets will be monitored and if it is considered necessary by ICL
Pathway, difficulties reported to the HSH will be elevated to NWB Business Incident
status.
Business Incidents Raised via the HSH by ICL Pathway / MSU
MSU will raise an appropriate Business Incident via the HSH for all exceptions
appearing on reconciliation report NB102 sections 2,3,4 and 5.
Business Incidents Raised via the HSH by POL
It is important that POL TP / BSM supply sufficient information to the HSH when
generating a NWB Business Incident in respect of a reconciliation or settlement error
to ensure the timescales for the resolution of NWB Business Incidents referred to in
section 6.0 can be achieved. Achievement of such timescales is dependent upon the
following information being provided by POL TP / BSM when generating a NWB
Business Incident via the HSH:
1. A valid ‘PATH’ code must be quoted, e.g. ‘*PATH040’ etc.
2. Prefix all narrative with ‘THIS IS A BUSINESS INCIDENT FOR MSU’
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 19 of I
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
3. The following transaction detail:
© Client Account Number (the PAN)
¢ Outlet FAD
¢ Value of transaction
¢ Date of transaction
NB: Where POL TP / BSM raise a NWB Business Incident which may require a large
amount of supporting information, summary detail only may be given to the HSH and
the additional information may be sent via e-mail to ICL Pathway / MSU. (A current
ICL Pathway / MSU contact list will be made available to POL).
4.3.3 Disputed Transactions Raised via the Enquiry Service
This facility is to support requirement NBR260 in respect of disputed transactions
where POL have received notification via either the outlet or the Network Business
Support Centre (NBSC). POL / TP / BSM will contact ICL Pathway / MSU directly
by telephone, requesting urgent investigation within the timescales quoted in section
4.4.3.1
Achievement of such timescales is dependent upon the following information being
provided by POL TP / BSM when generating a disputed transaction enquiry via the
Enquiry Service:
1. A valid ‘PATH’ code must be quoted, e.g. ‘PATH040’ etc.
2. The following transaction detail:
¢ Client Account Number (the PAN)
¢ Outlet FAD
¢ Value of transaction
¢ Date of transaction
NB: If incorrect or insufficient information is provided by POL to ICL Pathway to
allow resolution of the query, no further action will take place until new information
is supplied and the query will not be monitored in accordance with the timescales
referred to in section 4.4.3.1.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 20 of 1
ICL
Ltd
FUJ00120466
FUJ00120466
Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
4.4
4.4.1
4.4.1.1
4.41.2
NWB Incident Reporting
BIMS Reports / MER
The Business Incident Management System (BIMS) has been designed to report the
progress to resolution of an NWB Business Incident to allow POL / TP to complete an
accurate reconciliation (within POL central systems) or settlement with their clients.
For ease of identification and association with the corresponding HSH call, BIMS
Report references will mimic the HSH reference. However they will be prefixed with a
letter ‘B’, e.g. HSH ref.: E9912120011 = BIMS ref.: BE9912120011. Where an
incident has been raised via the Enquiry Service, an initial response will be provided via
telephone to POL / TP / BSM and followed up by an appropriate BIMS report.
Format & content of BIMS report / MER
A BIMS Report will be issued for each NWB Business Incident generated via the HSH
and the Enquiry Service. As part of that BIMS report, ICL Pathway will issue a MER
for each error associated with the relevant NWB Business Incident where it is
necessary to do so, to advise POL / TP of the transaction detail required to enable
reconciliation or settlement to take place.
BIMS Reports / MER are designed to notify POL / TP of the detail required to assist
in the reconciliation or settlement process within POL / TP. They communicate
information concerning the resolution of the symptom of an underlying cause, not the
cause itself. BIMS Reports / MER will not advise any detail as to the underlying
‘Cause’ of the problem if this is a result of a software error etc. This information is
supplied via the System Incident Log (SIL). Where a System Incident is generated to
eradicate the cause of a particular problem and there are one or more associated NWB
Business Incidents, cross-references will be supplied on the NWB Business Incident
BIMS Report / MER and the SIL to allow tracking of the System Incident.
Clearance & Closure Criteria
ICL Pathway anticipates that it will provide information concerning NWB Business
Incidents to POL / TP on a ‘drip feed’ basis, by issuing updated versions of the initial
BIMS Report / MER.
A BIMS Report is ‘Cleared’ when ICL Pathway / MSU has provided the reconciliation
/ settlement information required to be contained in the relevant BIMS Report as set
out in section 4.4.1.1. Additionally, the exception is cleared from the appropriate
section of NB102 by MSU. The BIMS Report is then ‘Closed’ following agreement
between POL / TP and ICL Pathway / MSU at the monthly TIP Operational Review
Forum (TIPORF). Such agreement is subject only to fulfilment of the following
conditions:
e Ifthere is no associated System Incident, the BIMS Report is closed subject to the
clearance criteria described above being met
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 21 of I
ICL
Ltd
FUJ00120466
FUJ00120466
Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
4.4.1.3
4.4.2
e If there is an associated System Incident, the BIMS Report is closed subject to the
successful closure of the System Incident by ICL Pathway / MSU. (On some
occasions however, it is expected that POL / TP will give authority to close a
BIMS report prior to the closure of the System Incident).
POL / TP will advise [CL Pathway / MSU via spreadsheet on a monthly basis at the
monthly TIPORF of any payments it considers are payable to POL (as compensation
for POL’s costs in dealing with MER) and / or its charges for dealing with widespread
errors. For the avoidance of doubt, NO charges are payable in respect of MER
issued for NWB incidents not affecting the TIP transaction stream.
If the parties disagree whether the TIP transaction stream has been affected or not, this
will be initially discussed at the monthly TIPORF. The specific incidents will then be
escalated via a ‘Case Law Referral’ form, to the Contract Administration Board for a
final decision to be made.
BIMS Report Distribution
ICL Pathway / MSU will distribute NWB BIMS Reports / MER within POL / TP
using the POL corporate e-mail network. In the event that this facility is temporarily
unavailable, reports will be distributed via the ICL Pathway mail system.
BIMS Reports / MER distributed in accordance with this section will be deemed to
have been issued to POL / TP, and / or POL / TP given notice of any errors described
therein, at the time of transmission by mail.
An example of a BIMS Report / MER is shown in Section 5.0.
System Incident Log
The SIL is intended to track the progress to resolution of a System Incident generated
to eradicate an underlying system fault. In practice, one system fault could lead to a
number of symptoms generating NWB Business Incidents. The SIL has been
developed to remove the need to annotate each BIMS Report / MER associated with a
particular system fault, with the detail required to ensure POL / TP are fully advised as
to the nature of this fault and how and when it is to be rectified. This information will
be contained in the SIL. NB: The SIL is not intended to be a vehicle to relay detail
of all ICL Pathway releases / fixes and will relate only to reconciliation incidents
resolved by MSU.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 22 of I
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
4.4.3 NWB Exception Resolution Timescales
4.4.3.1 NWB Business Incident SLA conditions
ICL Pathway / MSU will raise an initial BIMS Report (V1.0) relating to a new NWB
Business Incident, on the same working day as the NWB Business Incident is
generated via the HSH or the Enquiry Service, or in any event on the morning of the
next working day. This will be made available in accordance with section 4.4.1.1, to
POL / TP. This initial, incomplete, BIMS Report will serve to notify POL that a
Business Incident has occurred and that the completed BIMS Report will be provided
to POL within the agreed timescales below.
In the event of the NWB Report Set not being available to ICL Pathway / MSU in time
to enable any exceptions to be notified within this timescale, ICL Pathway / MSU will
contact the POL / TP ‘Incident Manager Transaction Processing’ to agree a
temporary extension to the timescale.
All enquiries and transaction searches within 90 days of the original transaction date
will be carried out by ICL Pathway / MSU via the DRS Workstation. Enquiries and
transaction searches where the original transaction date is in excess of 90 days will be
carried out by ICL Pathway / MSU using the Audit Archive subject _to POL
agreement to this archive being used for this purpose.
ICL Pathway / MSU will ensure the final cleared BIMS Report / MER, is made
available in accordance with section 4.4.1.1.and is cleared in accordance with the
following timescales:
1. For disputed transaction enquiries relating to system states 8,9,10 & 11 (defined as
“Customer Critical’ exceptions) where the transaction date is within 90 days of
the date the transaction is disputed by the end customer and raised by POL /
TP / BSM via the Enquiry Service in accordance with section 4.3.3:
¢ Ifthe disputed transaction is notified BY THE END of the MSU day where an
exception appears within NB102 section 5 — i.e. the day following receipt by
the DRS of a transaction within system states 8,9,10 or 11:
It must be resolved within an average time of <= 8 hours of notification,
based upon all exceptions received within a monthly reporting period.
e If the disputed transaction is notified AFTER THE END of the MSU day
where an exception appears within NB102 section 5 — i.e. the day following
receipt by the DRS of a transaction within system states 8,9,10 or 11:
It must be resolved within an average time of <= 8 hours commencing at
08.00hrs on the SECOND MSU day following receipt by the DRS of the
exception, based upon all exceptions received within a monthly reporting
period.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 23 of I
ICL
Ltd
FUJ00120466
FUJ00120466
Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
4,4,.3.2
2.
ey
For any disputed transaction enquiries relating to system states 8,9,10 & 11
(defined as ‘Customer Critical’ exceptions) where the transaction date is in
excess of 90 days of the date the transaction is disputed by the end customer
and raised by POL / TP / BSM via the Enquiry Service in accordance with section
4.3.3:
¢ It must be resolved within 5 MSU days notification
For any exception relating to incomplete states 8,9,10,11 reported within NB102
section 5 and raised by ICL Pathway / MSU via the HSH in accordance with
section 4.3.1:
e It must be resolved within an average time of <= 8 hours commencing at
08.00hrs on the SECOND MSU day following receipt by the DRS of the
exception, based upon all exceptions received within a monthly reporting
period.
For ALL other NWB exceptions reported within NB102 sections 1 — 5 and raised
via the HSH by ICL Pathway / MSU in accordance with section 4.3.1:
¢ They must be resolved within 5 MSU days of notification via NB102 sections
1-5.
For ALL NWB reconciliation errors raised by POL / TP / BSM via the HSH in
accordance with section 4.3.2:
e They must be resolved within 5 MSU days from the date they were reported
to the HSH.
NB: All time is calculated using the MSU day (08.00 to 17.30) and Monday to Friday
inclusive, excluding English bank holidays.
SLA Exclusions
Where an exception is identified as having it’s root cause outside of the ICL
Pathway domain the exception will be removed from the SLA calculation and
resolved using ‘Reasonable Endeavours’.
Where an exception has been generated due to factors outside of ICL Pathway’s
control, e.g. where an outlet has failed to communicate due to fire, flooding or
other agreed ‘Force Majeur’ conditions, the exception will be removed from the
SLA calculation and resolved using ‘Reasonable Endeavours’.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 24 of I
ICL
Ltd
FUJ00120466
FUJ00120466
Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
44.3.3
4.4.4
4.4.5
NWB System Incident Resolution Timescales
There is no strict timescale for the resolution of a System Incident as the time taken to
develop a fix or correct erroneous reference data cannot be determined. Obviously
however, ICL Pathway will give every System Incident the priority it deserves taking
into account POL’s requirement and would aim to deliver an initial analysis of the root
cause within 5 working days and a final analysis and evidence of remedial action,
within 10 working days. A System Incident will be closed by ICL Pathway once the
relevant fix has been developed and tested, or a correction to the relevant erroneous
reference data has been authorised or approved for release through the appropriate
agreed procedures between ICL Pathway and POL. The SIL, advising the current
status of System Incidents will be delivered to POL / TP at the end of each week. POL
/ TP may telephone ICL Pathway / MSU at any time to receive an update as to the
status of any System Incident documented on the SIL.
Widespread Errors
ICL Pathway will monitor ‘trigger points’, for example HSH calls and the NWB
Report set, which can alert of any likely potential or actual ‘widespread’ errors which
may occur. This is generally agreed to be the case where at least 100 exceptions of the
same System State are reported within NB102 sections 2,3,4 & 5. In such a case, a
problem will be raised and passed from ICL Pathway into the POL business
community.
Should this scenario occur, ICL Pathway Business Continuity Manager will
immediately notify POL Business Continuity Manager of the widespread error. Upon
giving such notice the provisions of this document (other than this section) shall cease
to apply to that particular widespread error. Instead, a recovery plan applicable to the
specific nature of the error will be agreed by both parties.
Repairing Data
Refer to ICL Pathway document ‘CS/PRO/II1 ‘TPS Reconciliation & Incident
Management’ for the repair criteria in relation to NWB transactions affecting the TPS
transaction stream.
© 2001
ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 25 of I
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
5.0 NWB BIMS Report
BIMS Reference: BE/0110150400 Final Update
. . Network ton: . +40:
Incident Type: 4 Banking Version: 3 Last Updated: 18/10/01 11:40:19
Incident Class: 0070 C2 with no corresponding C4, S or D
Originator: PW-MSU Transaction Date: 14-Oct-01 CAP: 3001 FAD: 004546
Status: 0 Open Exception Value: £10.00
Other References Transaction Liability
PinICL Reference: Provisional: Final:
Incident Xref: Settlement Details
TIP/TP/OSG Ref: Transaction Settlement
System Incident References Settled Amount:
HSH: Invoice Number:
PinICL: Invoice Date:
Manual Error Report
Incident History Chargeable Errors: 0
Date Received: 15-Oct-01 MER Set Amt:
Date Cleared: 16-Oct-01 MER Inv No:
Date Closed: MER Inv Date:
Actions
a 7 15/10/01 Describe .
Actions: Date & Time 14.93.49 Action Type Incident Analyst Dina Chauhan
The NBE/DRS Reconciliation Statement (NB100a) for processing date 15/10/01 shows 1
NBE/DRS Exception for £10.00. This is a C12 with no corresponding C4, S or D.
The customer details are
Bank — Barclays
Actions: Date & Time te oeod Action Type Clear Incident Analyst — Mike King
This occurred due the C12 not being delivered to the NBE. The C12 has now been forwarded
to the NBE by MSU
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 26 of 1
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
6.0 Incomplete and Exception States
6.1. Incomplete States
Incomplete Transaction Components
State
ci2 cz C4 Ss D
1 Vv
2 Vv V
4 Vv
5 Vv
6 Vv Vv
7 Vv Vv
8 Vv
9 v v
10 v Vv
ul V Vv V
12 Vv
13 Vv Vv
14 V V
15 Vv Vv V
16 Then ¥ v
17 Vv Then V Vv
18 v Then V V
20 V Then ¥
21 v V Then ¥
22 v V Then ¥
23 V V Vv Then V
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 27 of 1
ICL Pathway Network Banking Reconciliation & Incident
Ltd Management
FUJ00120466
FUJ00120466
Ref: NB/PRO/002
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
6.2 Exception States
Exception Description
State
E01 IAdditional C112
E02 IAdditional C12
E03 [Additional D
E04 (Additional C4
E05 \Additional S
E06 IS after C4
E07 \S after D
E08 (C4 after D
E09 [D after C4
E10 (C112 after final state
Ell (C12 afier final state
El2 4 afier final state
E13 [D after final state
El4 S after final state
EIS lot Used
E16 lot Used
EI7 lot Used
E18 lot Used
E19 lot Used
E20 [Amount of C112#C12
E21 [Amount of C112#C4
E22 [Amount of C112#S & C1#0.
E23 IAmount of C12#C4
E24 ‘Amount of C12#S & C12#0.
E25 [Amount of C112#D.
E26 [Amount of C12#D
E27 [Incomplete/corrupt C112
E28 Incomplete/corrupt C12
E29 IIncomplete/corrupt C4
E30 [Incomplete/corrupt D.
E31 Incomplete/corrupt S
E32 [Amount of C4#S & C4#0.
E33 ‘Amount of D#S
E34 (C112 arrived after state F99
E35 (C12 arrived after state F99
E36 IC4 arrived after state F99
E37 [D arrived afier state F99
E38 S arrived after state F99
E39 Settlement Date # Reconciliation Date
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 28 of 1
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
7.0 Incident Management Process Flows
7.1 Incomplete & Exception State Process Matrix
Ral DESCRIPTION
NGI GROUP STATENO.
ni fee oe Lee 5 ;
8 I 213832
ce I 4121020
oe oe ne jee cz ana ct ¢ . 5
e 6
See ee ad
+ rf naaaras
Imewscrarser I &
eo a aA = 5
PA le hf cc 7 :
lees Cana Ct nd Oho) S I
Pes Pe en Pee I 8,00,00 ri .
1 seis Chanda Dard
ee Se x ee e000 2 10
lines Grand G4 rand} :
ci Daas x _Ice 88,00 x 2,18
I IWhewiscrerDendce IG
MOEA CD ele le I a Key:
[mere is 2 ana ct &
Bop ie a BB.00
1) * IED found it must be investigated
Bo vi os eee 8 68
2) CE = Customer Enquit
Bole oe a I ae co uy
ee ; ak
ev Ix fee is cr ana co Lc nates
. I een Jf ae
lume is ct
FUJ00120466
FUJ00120466
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 29 of 1
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
7.2 MSU Network Banking Top Level
MSU - Network Banking
or Request
aise } for
PinicL Bim Raise Phone Enquiry assistance
Raise BIMS Process. BIMS Process. Give
(PON: —o Telephone
HSH) feedback
BIMS reports
Report analysis
Raise BIMS
—
Report production
‘and checking
Reports.
Reconciliation Reports
--4---------- siniosyi0-
NN
Start of Process End of Process External process Internal Process box Decision box Connector
intemal Process box
with sub processes within
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 30 of I
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
7.3 Reconciliation Report Production and Checking Process — Level 1
Pathway Reports placed TP Reports placed on
Campus gateway DRS
¥
Telephone Enquiry “
ovese Analyse reports BIM process { END
MSU
Backup reports
(if required)
,---~---------}-1----------------I------- OLA Point» — ~~ ----------------------------------4
TP
(POL)
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 31 of I
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
7.4 Reconciliation Report Analysis — Level 2
tial apart
masuy
4
‘check report for
aii
meet aC ee)
'
Page 32 of 1
FUJ00120466
FUJ00120466
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
ICL Pathway Network Banking Reconciliation & Incident
Ltd
Management
COMMERCIAL IN CONFIDENCE
Ref: NB/PRO/002
Version: 1.0
Date: 19/12/01
7.5 Enquiry Service Process — Level 1
FUJ00120466
FUJ00120466
1P
(POL)
pe beeen OLA Pol = bp ma a a a ened
Irvestiate BIM process (exo
MSU
(enn)
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 33 of 1
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
7.6 Enquiry Service — Investigate — Level 2
Log cal nto
Enqui ‘enquiy database
Database (su)
(Check ORS
(wsu)
L™ ‘Close associated
0 POL agree Bus paonenay I _/ »)
Yeo raise oS? database adding I»{ END)
IMS! erate BIMS?, PROCESS: BIMS ref no to og )
. (Msu)
N
¥
Infom POL of
investigation
findings [#
(MSU)
FUJ00120466
FUJ00120466
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 34 of 1
ICL Pathway Network Banking Reconciliation & Incident
Ltd
Management
COMMERCIAL IN CONFIDENCE
Ref:
Version:
Date:
NB/PRO/002
1.0
19/12/01
7.7 BIMS Process — Level 1
HSH
Log call and route
wousu
msu
BIMS Process
+
Raise aS
oT!
PiniCL
FUJ00120466
FUJ00120466
© 2001 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE
Page 35 of 1
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
FUJ00120466
FUJ00120466
7.8 BIMS Process — Level 2
/ Prompt tor
wore
HsHIPOL!
usu
t
Vie #SAr
(usuiPou)
H
Copied onto
Pinicl.
corr tin)
incorporate
Powerelp Ret
su}
MSU Incident
-
(su)
Hl
ASSES
ws)
Update (Sit)
(wsu)
Raise System
(ws)
SSSGSASSS
Add aysiom
PF Bhusisit report
usu)
SSS
Seng amsisit
report to POL
Move te close
Do POL agra
clear sis
su)
ape
Until system
incident
¥
Request to POL
for permission to
Fei
© 2001 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Page 36 of 1
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
7.9 Process AA — Location of missing C4, S or D Transaction Component
Locate C4 or
Dors
Mateh C4 with C12 .
miners an ret > smserocess fe END )
~ orphan C4 usu) .
T
N
¥
Ne C12 corrupt >—N&<
Match § with C12
N8 there any ee tia
orphans
Forward to NBE
7 v (MSU)
insu . 7 .
i
¥
etn any __,I Nateh o.wito12 aims process
<'srpnan 3) > 1 (System incident) 1
] Receive c4 or D
A ( ) ‘wou
BIMS PROCESS
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 37 of I
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
7.10 Process BB — Location of Missing C112 Transaction Component
Locate
on
Has outlet
polled?
* a
3
orphan c112. > C1201 C4 BIMS PROCESS END
\
N—»I Unti outlet polis.)
(usu)
me
N
¥
Ae there at Va
EPOSS REC >——Y—m, BIMS PROCESS END )
er eror )
Y
N
BIMS PROCESS
(System Incident)
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 38 of I
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
7.11 Process CC — Location of Missing C12 Transaction Component
/ Locateci2 /
4 . Match 612 with ca ——————
Is mere any oretie sins PRocess (eno
<pran (usu) -
N
Has
Is oS O12 availabie
“C12 been 7 ~ Ma Forward to NBE
© igen es to N-m< 612 corrupt >-N-m< tobe DY aNeu)
wee delivered to
NBE?
i
Y
¥
BIMS PROCESS
(System Incident)
yo
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 39 of I
FUJ00120466
FUJ00120466
ICL Pathway Network Banking Reconciliation & Incident Ref: NB/PRO/002
Ltd Management
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 19/12/01
7.12 Process DD - Customer Enquiry and Investigation of D Transaction Component Exceptions
"oer tt
Fa oui wow aus mn
Spates Y—T>< present? >>] PROCESS __ eNO
r
¥
check states of
outa (Real time)
su)
i LJ
outst
Forward to NBE
usu)
throughout day 8
‘(usu
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 40 of 1