Fujitsu Services
FUJ00120468
FUJ00120468
Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 19/12/02
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Originator & Dept:
Contributors:
Reviewed By:
Comments By:
Comments To:
Distribution:
Network Banking Reconciliation & Incident Management
Procedure
N/A
This document outlines the end-to-end reconciliation and incident
management procedures required to investigate, report and resolve
Network Banking reconciliation and business incidents.
APPROVED
Richard Brunskill (Fujitsu Services)
Fujitsu Services: Michael King, Angela Shaw
Fujitsu Services: Angela Shaw, Michael King, Mark Farry,
John Moran Mik Peach, David Hollingsworth, Tony Hayward
PON: Glenys Latham, Ijaz Bhatti, Claire Bennett, Jayne
Widdowson, Sharon Holness, Alan Orpe, Marian Dale, Jeanette
Brown
N/A
N/A
Document Management
Reviewers
© 2002 Fujitsu Services Ltd
COMMERCIAL IN CONFIDENCE Page I of 25
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
5.0
COMMERCIAL IN CONFIDENCE Date: 19/12/02
0.0 Document Control
0.1. Document History
\Version No. {Date [Reason for Issue IAssociated
(CP/PinICL
0.1 22/10/01 Initial Draft /A
1.0 19/12/01 Issued for Approval following PO Limited review IN/A
2.0 22/01/02 Post V1.0 PO Limited comments included to\N/A
enable final approval off by PO Limited
2.1 7/03/02 (Changes following the implementation of CR27\N/A
land output from the reconciliation report]
orkshop held on 20/21 February 2002
2.2 22/03/02 (Changes following N08 contractual discussions /A
2.3 22/04/02 (Changes following N08 contractual discussions &IN/A
re-branding of ICL Pathway to Fujitsu Services
3.0 10/05/02 Comments following PO Ltd Review. ForN/A
lapproval
4.0 15/12/02 Revised to remove references to Codified!
[Agreement Schedule G01 and replace with!
ICS/SER/017. Also to include references to
Service Level Targets and remedies payable in!
respect of Debit Card Method of Payment
(DCMoP)
5.0 19/12/02 [Updated for Contract Amendment. This versions
\does not include references to Service Leve'
[Targets and remedies payable in respect of Debit
(Card Method of Payment (DCMoP) — howeve:
these have been listed in 0.6 Changes Expected.
0.2 Approval Authorities
Name Position Signature ‘Date
[Richard Brunskill [Fujitsu Services — Pathway
Infrastructure Services
Manager
Liz Tuddenham Post Office Networ'
‘Support: Supplier & ServiceI
\Performance Manager
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE
Page 2 of 25
Fujitsu Services
Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 19/12/02
0.3 Associated Documents
Reference ersion Date [Title Source
1. CS/SPE/011 3.0 21/03/02 etwork Banking End to End IPVCS
[Reconciliation Reporting
2. CS/PRO/111 1.3 16/11/01 [TPS Reconciliation & IncidentP VCS
Management
3. CS/SER/017 1 15/12/02 [Data Error / Not Data Error PVCS
Definitions
0.4 Abbreviations/Definitions
[Abbreviation
Definition
[Business Incident
requiring investigation and the provision of corrective information to
ithe ‘Symptom’ and not to the root cause of the exception.
‘Any exception (as defined below) reported via NB102 or via the HSH
low PO Limited to settle or reconcile. A Business Incident relates to
(Customer Critical
[Exception
ave received a DBTN, (see below for definition).
\A Priority Exception (see below for definition) where Fujitsu Services
IDBTN
Disputed Banking Transaction Notice: Where Fujitsu Services has
eceived notification from PO Limited via the Enquiry Service
following a query by the ‘End’ customer relating to the state of his /
er account.
IEBBT
[Enquiry Based Banking Transaction: Where Fujitsu Services has
articular transaction.
received notification from PO Limited via the HSH wishing to query a
[Exception Types
Within all reports the ‘Exceptions’ category will include:
@ ‘Incomplete States’, i.e. those transactions where one or more
transaction component is missing — a C4 without a C12 ete
ie 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
IMSU Day
English bank holidays
‘Between 08.00hrs and 17.30hrs Monday — Friday inclusive, excluding
Priority Exception
message
‘An exception reported within NB102 section 5 relating to system)
states 4 or 12 following confirmation of a corresponding C4 or D)
‘System Incident
‘Any exception (as defined above) reported via NB102 or via the HSH
equiring the investigation and repair of the root cause of the)
exception.
IAPS ‘Automated Payment Service
IBIMS Business Incident Management Service
© 2002 Fujitsu Services Lid +COMMERCIAL IN CONFIDENCE Page 3 of 25
FUJ00120468
FUJ00120468
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 19/12/02
IBSM Business Service Management ( AP Service Provision Team — PO,
Limited)
IDRS [Data Reconciliation Service
IEPOSS Electronic Point of Sale Service
IHSH [Horizon Systems Helpdesk
MER Manual Error Report
MSU Fujitsu Services, Pathway, Management Support Unit
BE etwork Banking Engine
WB etwork Banking
PO Limited 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
\Version (Changes
1.0 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
Re- structuring of document following PO Limited review
2.0 fe Late comments included to enable approval by PO Limited: See
section
4.4.3.1 — ‘Customer Critical Exceptions’ included in points I and 3.
2.1 Re issue for review following changes resulting from CR27 and
orkshop held on 20/21 February 2002.
e System States 8,9,10 & 11 ‘Customer Critical’ exceptions replaced)
by System State 4.
@ Reports NB100a & NB100b now deleted from report set
@ Reports NB10la & NB101Ib now deleted from report set and
replaced with new report NB101
fe Widespread error provisions and monitoring amended to agree
with schedule N08 — now section 4.4.2.
fe Contingency for report distribution to PO Limited amended to
include NB101 and NB102 sections I and 2
e SLA definitions amended to agree with schedule N08 — no
section 4.4.1.
@ Process maps for incident management, section 7 are deleted. Will
be scoped and agreed in a separate non CCD
© 2002 Fujitsu Services Lid +COMMERCIAL IN CONFIDENCE Page 4 of 25
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 19/12/02
@ Caveat to exclude ‘S’ transactions from Network Banking reports,
(EFTPOS reports will be populated with ‘S’ transactions)
2.2 IRe-issue following NO8 contractual agreement:
.3: Deletions from associated documents and the inclusion ofj
(CS/PRO/111
(0.4: Definition added for Priority Exception
4.4.1: SLA measurements and criteria brought in line with NO8
4.4.2: Widespread error definition brought in line with NO8
5.0: Amendments to BIMS report example
6.0: Tables brought in line to those quoted in CS/SPE/O11
2.3 4.4.1 Amendments to Priority Exception SLA measurement from
‘Average’ time to 95% target time.
4.4.2 Amendments to the Widespread Error provision following final
agreement of NO8
IRe-branding of ICL Pathway to Fujitsu Services throughout document
3.0 Final POL (Glenys Latham) comments included.
5.0 (Updated for Contract Amendment. This versions does not include
eferences to Service Level Targets and remedies payable in respect ofj
[Debit Card Method of Payment (DCMoP) — however these have been!
listed in 0.6 Changes Expected. Minor typos corrected.
0.6 Changes Expected
\Changes
IUpdate required to include references to Service Level Targets and remedies payable in respect
of Debit Card Method of Payment (DCMoP)
© 2002 Fujitsu Services Lid +COMMERCIAL IN CONFIDENCE Page 5 of 25
FU.
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
5.0
COMMERCIAL IN CONFIDENCE Date: 19/12/02
0.7 Table of Contents
1.0 INTRODUCTION...
2.0 SCOPE....
3.0 REPORTS PRODUCED BY PATHWAY CENTRAL SYSTEMB.........
3.1 NB101 — NETWORK BANKING SETTLEMENT STATEMENT 9
3.2 NB102 — EXCEPTION SUMMARY. 10
3.3. NB103 — SETTLED TRANSACTION / CASH ACCOUNT RECONCILIATION STATEMENT... 12
3.4. REPORT DISTRIBUTION & CHECKING...
3.4.1 Contingency in the Event on Non delivery of reports to PO!
4.0 RECONCILIATION & INCIDENT HANDLING........
4.1 INCIDENT CLASSIFICATION
4.1.1 I NWB Business Incidents.
4.1.1.1 I NWB Reconciliation Report Exceptions. 15
4.1.2. NWB System Incidents.
4.2 GENERATION OF BUSINESS INCIDENTS
4.2.1 NWB Business Incidents Raised via the HSH by Pathway / MSU..
4.2.2. NWB EBBT Business Incidents Raised via the HSH by PO Limited.
4.2.3. DBTN NWB Business Incidents Raised via the Enquiry Service.
4.3. NWB INCIDENT REPORTIN
4.3.1 BIMS Reports / MER
43.1.1 Format & content of [S repor
4.3.1.2 Clearance & Closure Criteria.....
43.1.3 BIMS Report Distribution.
4.3.2 System Incident Log.
4.4 NWB EXCEPTION RESOLUTION TIMESCALES.
4.4.1 I NWB Business Incident SLA conditions..
.1 SLA Exclusion / Suspension criteria.
2 NWB System Incident Resolution Time:
4.4.2 Widespread Errors....
4.4.2.1 Widespread Error Conditiot
4.4.3 Repairing Data.......
5.0 NWB BIMS REPORT......
6.0 INCOMPLETE AND EXCEPTION STATES...
6.1 INCOMPLETE STATES..... sossneesennnneneeees
6.2 EXCEPTION STATES...
© 2002 Fujitsu Services Lid +COMMERCIAL IN CONFIDENCE Page 6 of 25
FUJ00120468
}J00120468
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
5.0
COMMERCIAL IN CONFIDENCE Date: 19/12/02
1.0 Introduction
The Network Banking (NWB) report set produced by Fujitsu Services — Pathway (
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 (PO Limited) clients, e.g. Link, or direct settlement to specific
clients.
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 PO Limited central systems — the Cash
Account.
In addition to those exceptions reported by Pathway within the NWB report set,
reconciliation errors may be discovered by PO Limited when reconciling data within
it’s central systems or relating to queries from PO Limited clients. To initiate the
Business Incident Management Service (BIMS) process, Pathway or PO Limited
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 PO
Limited Transaction Information Processing (TIP), the provisions quoted within the
CCD entitled: CS/SER/017 ‘Data Error / Not Data Error — Definitions, 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 documented within the CCD entitled: CS/SER/017 ‘Data Error / Not Data
Error — Definitions; where the incident has caused a reconciliation or settlement error
within TIP are found in associated Pathway CCD entitled: ‘CS/PRO/I11: TPS
Reconciliation & Incident Management’
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 7 of 25
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
5.0
COMMERCIAL IN CONFIDENCE 19/12/02
2.0 Scope
This document sets out the reconciliation and incident management procedures to be
adopted by Pathway / Management Support Unit (MSU) for dealing with NWB
reconciliation report distribution to PO Limited and any associated NWB Business
Incidents which may arise, including:
NWB reconciliation report exceptions and incomplete states
Software faults affecting reconciliation and settlement
PO Limited client enquiries / disputed banking transactions
NWB Reconciliation Reports
eceee
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 8 of 25
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 19/12/02
3.0 Reports produced by Pathway central systems
This section is intended to give an overview of the working of each reconciliation report
available. It is not intended as a reference point in the design of the reports, as such any rules
or definitions quoted within the associated CCD ‘CS/SPE/001: NWB End to End
Reconciliation Reporting’, will take precedence.
3.1. NB101— Network Banking Settlement Statement
This report provides settlement information based upon the ‘Client View’ where C4
transaction components have been received by the DRS.
1
C4 Settlement Date 1 — This figure identifies all C4 transaction components
received by the DRS from the NBE with a ‘C4 Settlement Date’ = to the Run Date
of the report.
C4 Settlement Date 2 — This figure identifies all C4 transaction components
received by the DRS from the NBE with a ‘C4 Settlement Date’ = to the Run Date
of the report minus I day if any C4 transactions received for this date.
C4 Settlement Date 3 etc — This figure identifies all C4 transaction components
received by the DRS from the NBE with a ‘C4 Settlement Date’ = to the Run Date
of the report minus 2 days if any C4 transactions received for this date. (Repeat for
each day where C4 transactions have been received)
Total of all C4 transactions received on this report.
Columns: Representing volume and value of Deposits, (titled ‘Receipts’) and
Withdrawals, (titled ‘Payments’).
Net Settlement column showing volume and value where:
¢ Volume = number of deposits plus number of withdrawals
e Value = value of deposits minus value of withdrawals
e Where the value of withdrawals exceeds the value of deposits, this total is
shown as (£9999.99)
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 9 of 25
3.2
FUJ00120468
FUJ00120468
NB102 — Exception Summary
The report identifies all incomplete or exception states.
This report is divided into 12 sections:
Section 1: All Uncleared confirmed, unconfirmed and TIP exceptions
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: Uncleared 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. NB: For Network Banking, this
section is generally not expected to be populated due to the exclusion of ‘S’ type
transactions from this stream.
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 1 and listed individually in system state and
reconciliation date order.
Section 6: Uncleared future dated transactions by client
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: All Cleared confirmed, unconfirmed & TIP exceptions
e As section 1 — exceptions cleared and set to ‘F99’ by Pathway MSU
Section 8: Cleared exceptioned client transactions
e As section 2 — exceptions cleared and set to ‘F99’ by Pathway MSU
Section 9: Cleared corruption’s
e As section 3— exceptions cleared and set to “F99’ by Pathway MSU
Section 10: Cleared timing differences
e As section 4 — exceptions cleared and set to ‘F99’ by Pathway MSU
Section 11: Cleared confirmed, unconfirmed & TIP exceptions >24 hrs
e As section 5 — exceptions cleared and set to ‘F99’ by Pathway MSU
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 3.0
COMMERCIAL IN CONFIDENCE Date: 10/05/02
Section 12: Cleared future dated transactions by client
e As section 6 — exceptions cleared and set to ‘F99’ by Pathway MSU
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 11 of I
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 3.0
COMMERCIAL IN CONFIDENCE Date: 10/05/02
3.3. NB103 — Settled Transaction / Cash Account Reconciliation
Statement
This report allows PO Limited to reconcile the settlement stream against the outlet
Cash Account stream. This reconciliation is required as settlement with the individual
PO Limited clients is based upon ‘C4 Processing Date’ i.e. the business day upon
which the settlement took place. To complete a full reconciliation, it is important to
know which Cash Account the settled transaction was posted to, to enable a
reconciliation of settlement to be made with the outlet records. This report reconciles
the transactions by ‘C4 Processing Date’ and Cash Account record.
1. NB103 is run weekly: In order to align with internal PO Limited / 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 transaction
components where:
© ‘C4 Processing Date’ = run date and,
¢ ‘C4 Processing Date’ = run date minus ‘N’ (where ‘N’ = I to 13).
2. Where a C112 is available and the Cash Account Period (CAP) is known the C4
transaction value will be posted against the appropriate CBDB CAP column.
3. Where a C112 is available and the CAP is known, but there is no C4, it will not be
reflected in this report because the report includes C4 transaction values only
4. Where no C112 is available and therefore the CAP is unknown:
e the C4 transaction value will be posted to ‘No Cash Account Allocated’
e then, when the C112 becomes available, the entry will be deleted from ‘No
Cash Account Allocated’ and posted to the appropriate CBDB CAP column
e ifno C112 has been received after 14 days, the entry within ‘No Cash
Account Allocated’ will remain until the C112 becomes available even if
this exceeds 14 days
5. If a transaction is posted to the row ‘No C/A to TIP’ (according to rules 2 & 4
above):
e 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’ will remain until the Cash Account is delivered to TIP
even if this exceeds 14 days
6. 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 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
7. Where the columns headed ‘CAPXX’ are referred to, the actual report produced
will show the actual CAP number, for example CBSB CAP40 is quoted, the
column ‘CAPXX<=-2’ will show ‘CAP40<=-2’.
8. This report identifies VALUE only
9. A separate report NB103 will be produced for both Deposit and Withdrawal
transactions derived from ‘Txn_type’”
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 12 of I
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 3.0
COMMERCIAL IN CONFIDENCE Date: 10/05/02
10. Five CAP’s will be shown. The Counters Business Database (CBDB), the CBDB
11.
13.
14.
minus 1, the CBDB <=minus2, the CBDB plus I and the CBDB >= plus 2. In
addition, those settled transactions, which currently have not been allocated a Cash
Account are shown.
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).
. 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.
The C4 processing dates will be shown in reverse chronological order.
For a given C4 Processing Date, the sum of the two Total values (for the two rows
C/A to TIP and No C/A to TIP) should be equal to the Total corresponding
Receipts and Payments value on report NB101 for the same run date
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 13 of I
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 3.0
COMMERCIAL IN CONFIDENCE Date: 10/05/02
3.4 Report Distribution & Checking
3.4.1
Both daily and weekly reports will be available by 08.00hrs the day following the run
date of the report to:
e PO Limited / 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 Pathway / 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.
Contingency in the Event on Non delivery of reports to PON
If Pathway is unable to deliver all or any individual report to the PO Limited / TIP
gateway by 08.00hrs the day following the run date of the report, Pathway MSU
Manager will liase with the Network Banking Settlement Team Leader PO Limited /
TP to arrange an e mail transmission via the Pathway account within the PO Limited
corporate mail system of reports NB101_ and NB102 section _1_and_section 2.
Pathway / MSU will operate this contingency under ‘reasonable endeavours’ and will
aim to have the reports with PO Limited 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 PO Limited corporate mail system be unavailable to
Pathway, then Fujitsu Services Corporate mail is used as an alternative.
NB: Should the corporate e mail service of either organisation be unavailable, the
Manager Pathway / MSU will liase with the Manager PO Limited / TP and agree
facsimile of reports NB101 and NB102 section I and 2.
Any distribution list for these reports is considered by both Pathway and PO Limited to
be of a dynamic nature and therefore specific addressees are not covered within this
document.
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 14 of I
FU.
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 3.0
COMMERCIAL IN CONFIDENCE Date: 10/05/02
4.0 Reconciliation & Incident Handling
4.1
4.1.1
41.1.1
4.1.2
Incident Classification
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 PO
LIMITED.
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 PO Limited / 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).
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 to be harvested
Corruption’s within the NBE / DRS
NWB System Incidents
System Incidents relate to the underlying ‘Cause’
Following the creation of a NWB Business Incident, 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 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.
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 15 of I
FUJ00120468
}J00120468
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 3.0
COMMERCIAL IN CONFIDENCE Date: 10/05/02
4.2 Generation of Business Incidents
4.2.1
4.2.2
In line with the generic incident management PO Limited policy agreed between
Pathway and PO Limited, NWB Business Incidents will only be recognised as such if
generated by Pathway or PO Limited as appropriate, via the HSH or via the ‘Enquiry
Service’. This ensures that the NWB Business Incident is properly logged, enabling
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 Pathway and PO Limited:
e Pathway / MSU for all exceptions reported via the NWB Report Set
¢ PO Limited TP / BSM for any “Enquiry Based Banking Transactions’ (EBBT) or
‘Disputed Transaction Notice’ (DBTN) discovered by PO Limited that has not been
reported by Fujitsu Services via the NWB report set
e Pathway / System Support Centre (SSC) for any system fault or data ‘surgery’
which is considered by Fujitsu Services to have a reconciliation or settlement
implication within PO Limited 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
Pathway, difficulties reported to the HSH will be elevated to NWB Business Incident
status.
NWB Business Incidents Raised via the HSH by Pathway / MSU
Pathway / MSU will raise an appropriate Business Incident via the HSH for all
exceptions appearing on reconciliation report NB102 sections 2,3,4 and 5.
NWB EBBT Business Incidents Raised via the HSH by PO
Limited
It is important that PO Limited TP / BSM supply sufficient information to the HSH
when generating a NWB Business Incident in respect of an EBBT NWB Business
Incident to ensure the timescales for the resolution of NWB Business Incidents
referred to in section 4.4 can be achieved. Achievement of such timescales is
dependent upon the following information being provided by PO Limitea 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’
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 16 of I
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 3.0
COMMERCIAL IN CONFIDENCE Date: 10/05/02
3. The following transaction detail:
© Client Account Number (the PAN)
¢ Outlet FAD
e Value of transaction
¢ Date of transaction
NB: Where PO Limited TP / BSM raise an EBBT 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 Fujitsu Services /
MSU. (A current Pathway / MSU contact list will be made available to PO Limited).
4.2.3 DBTN NWB Business Incidents Raised via the Enquiry Service
This facility is to support requirement NBR260 in respect of DBTN where PO Limited
have received notification via either the outlet or the Network Business Support
Centre (NBSC). PO Limited / TP / BSM will contact Pathway / MSU ‘Enquiry
Service’ directly by telephone, requesting urgent investigation within the timescales
quoted in section 4.4.1
Achievement of such timescales is dependent upon the following information being
provided by PO Limited TP / BSM when generating a DBTN enquiry via the Enquiry
Service:
1. A valid ‘PATH’ code must be quoted, e.g. ‘PATH040” etc.
2. The following transaction detail:
e Client Account Number (the PAN)
e Outlet FAD
¢ Value of transaction
¢ Date of transaction
NB: If incorrect or insufficient information is provided by PO Limited Pathway s to
allow resolution of the DBTN enquiry, no further action will take place until new
information is supplied and the enquiry will not be monitored in accordance with the
timescales referred to in section 4.4.1.
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 17 of I
FU.
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 3.0
COMMERCIAL IN CONFIDENCE Date: 10/05/02
4.3
4.3.1
4.3.1.1
4.3.1.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 PO Limited / TP to
complete an accurate reconciliation (within PO Limited 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 PO Limited / TP / BSM and followed up by
an appropriate BIMS report.
Format & content of BIMS report / MER
ABIMS Report will be issued for each NWB Business Incident generated via the HSH
and the Enquiry Service. As part of that BIMS report, Fujitsu Services will issue a
MER for each error associated with the relevant NWB Business Incident where it is
necessary to do so, to advise PO timitea / TP of the transaction detail required to enable
reconciliation or settlement to take place.
BIMS Reports / MER are designed to notify PO Limited / TP of the detail required to
assist in the reconciliation or settlement process within PO Limited / 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
Pathway anticipates that it will provide information concerning NWB Business
Incidents to PO Limited / TP on a ‘drip feed’ basis, by issuing updated versions of the
initial BIMS Report / MER.
A BIMS Report is ‘Cleared’ when Fujitsu Services / 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 PO Limited / TP and 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
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 18 of I
FUJ00120468
}J00120468
FU.
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 3.0
COMMERCIAL IN CONFIDENCE Date: 10/05/02
43.1.3
4.3.2
e If there is an associated System Incident, the BIMS Report is closed subject to the
successful closure of the System Incident by Pathway / MSU. (On some occasions
however, it is expected that PO Limited / TP will give authority to close a BIMS
report prior to the closure of the System Incident).
PO Limited / TP will advise Pathway / MSU via spreadsheet on a monthly basis at the
monthly TIPORF of any payments it considers are payable to PO Limited (as
compensation for PO Limited’s costs in dealing with MER). 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
Pathway / MSU will distribute NWB BIMS Reports / MER within PO Limited / TP
using the PO Limited corporate e-mail network. In the event that this facility is
temporarily unavailable, reports will be distributed via the Fujitsu Services mail system.
BIMS Reports / MER distributed in accordance with this section will be deemed to
have been issued to PO Limited / TP, and / or PO Limited / 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 PO Limited / 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 Pathway releases / fixes and will relate only to reconciliation
incidents resolved by MSU.
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 19 of I
FUJ00120468
}J00120468
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 3.0
COMMERCIAL IN CONFIDENCE Date: 10/05/02
4.4 NWB Exception Resolution Timescales
4.4.1 NWB Business Incident SLA conditions
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.3.1.1, to
PO Limited / TP. This initial, incomplete, BIMS Report will serve to notify PO
Limited that a NWB Business Incident has occurred and that the completed BIMS
Report will be provided to PO Limited within the agreed timescales below.
In the event of the NWB Report Set not being available to Pathway / MSU in time to
enable any exceptions to be notified within this timescale, Fujitsu Services / MSU will
contact the PO Limited / 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 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 Pathway / MSU using the Audit Archive subject to PO LIMITED
agreement to this archive being used for this purpose.
Pathway / MSU will ensure the final cleared BIMS Report / MER, is made available in
accordance with section 4.3.1.l.and is cleared in accordance with the following
timescales:
1. For DBTN enquiries where the transaction date is within 90 days of the date
the transaction is disputed by the end customer and raised by PO Limited / TP /
BSM via the Enquiry Service in accordance with section 4.2.3:
95% must be resolved within <= 8 hours of notification based upon all DBTN
enquiries (Customer Critical Exceptions) received within the quarterly reporting
period
The following conditions apply to DBTN enquiries:
The calculation of the time to resolution within the above SLA will only commence
from either the receipt of the C4 or D transaction component within the DRS, or
the reporting of a Priority Exception, (which becomes a ‘Customer Critical
Exception by way of the associated DBTN), within NB102 section 5 of the NWB
reconciliation report set.
2. For any DBTN enquiries where the transaction date is in excess of 90 days of
the date the transaction is disputed by the end customer and raised by PO
LIMITED / TP / BSM via the Enquiry Service in accordance with section 4.2.3:
e It must be resolved within 5 MSU days of notification
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 20 of I
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 3.0
COMMERCIAL IN CONFIDENCE Date: 10/05/02
3. For any ‘Priority’ exception relating to incomplete states 4 or 12, where a DBTN
4.4.1.1
4.4.1.2
enquiry has not been received, reported within NB102 section 5 and raised by
Fujitsu Services / MSU via the HSH in accordance with section 4.2.1:
95% must be resolved within <= 8 hours commencing at 08.00hrs on the
SECOND MSU day following receipt by the DRS of the exception, based upon
all Priority exceptions received within the quarterly reporting period.
For all non ‘Customer Critical’ NWB exceptions reported within NB102 sections
2 —5 and raised via the HSH by Pathway / MSU in accordance with section 4.2.1:
e They must be resolved within 5 MSU days of notification via NB102 sections
2-5.
For EBBT NWB reconciliation errors raised by PO Limited / TP / BSM via the
HSH in accordance with section 4.2.2:
¢ 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 Exclusion / Suspension criteria
Where an exception has been generated due to factors outside of Pathway 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’.
Where an exception necessitates the retrieval of information from, or access to, an
Outlet to enable successful resolution and this is not available. The period whilst
Pathway waits, having requested that information or access be provided, shall not
count towards the time for resolution of that exception.
Where resolution is dependent upon information being received from the NBE,
The period whilst Pathway waits, having requested that information or access be
provided, shall not count towards the time for resolution of that exception.
PO Limited will be informed via the BIMS report applicable to the exception being
investigated that SLA suspension is being invoked in respect of the above.
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
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 21 of I
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 3.0
COMMERCIAL IN CONFIDENCE Date: 10/05/02
however, Pathway will give every System Incident the priority it deserves taking into
account PO Limited’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 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 Pathway and PO Limited. The SIL, advising the current
status of System Incidents will be delivered to PO Limited / TP at the end of each
week. PO Limited / TP may telephone Pathway / MSU at any time to receive an
update as to the status of any System Incident documented on the SIL.
4.4.2 Widespread Errors
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.
4.4.2.1 Widespread Error Conditions:
Total Number of CCE Priority Exceptions which aren’t I Other Exceptions
Exceptions in the CCE’s
day
Up to 100 8 hr SLA 8 hr SLA 5 day target time
100 to 500 8 hr SLA 8 hr SLA unless there are more thanj5 day target time
100 in either state 4 or state 12 i
hich case those in that error state wil
lhave a Widespread Error ‘let’ to 5 da
target time, but all others to meet the 8}
hr SLA
(Over 500 8 hr SLA (Target time for Widespread Errors. _ [5 day target time
8 hr SLA for the first 500 which areI
mot Widespread Errors and 5 da
target time thereafter
4.4.3 Repairing Data
Refer to Pathway document ‘CS/PRO/II1 ‘TPS Reconciliation & Incident
Management’ for the repair criteria in relation to NWB transactions affecting the TPS
transaction stream.
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 22 of I
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 3.0
COMMERCIAL IN CONFIDENCE Date: 10/05/02
5.0 NWB BIMS Report
BIMS Reference: BE/0110150400 Final Update
A . Network Jon: . +40:
Incident Type: 4 Banking Version 3 Last Updated: 18/10/01 11:40:19
Incident Class: 0070 C4 with no corresponding C12
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
ji ‘ 15/10/01 Describe ‘
Actions: Date & Time 11:03:10 Action Type Incident Analyst Dina Chauhan
NB102 for processing date 15/10/01 shows 1 Exception for £10.00. This is a C4 with no
corresponding C12
The customer details are NB: This wording may not reflect the actual content
of
a BIMS report in live running. It has only been
Included by way of example
Bank — Barclays
PAN 000000000000000
FAD 000000
Actions: ., 16/10/01 ; ss -
\ctions: Date & Time 15:36:04 Action Type Clear Incident Analyst Mike King
C12 subsequently received on 16/10/01 for £10.00. Customer and settlement deemed to be
correct.
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 23 of I
FUJ00120468
FUJ00120468
Fujitsu Services Network Banking Reconciliation & Incident Ref: NB/PRO/002
Management
Version: 3.0
COMMERCIAL IN CONFIDENCE Date: 10/05/02
6.0 Incomplete and Exception States
6.1. Incomplete States
This table identifies the NB102 series report section where incomplete and discrepancy
States are reported in detail.
Incomplete Transaction Components Exception report NB102
State Section
C112 C12 C4 Ss D Uncleared I Cleared
I V 1&5 T&M
2 v v 1&5 7&ll
4 v 1&5 7&l
3 V 1&5 T&M
6 v v 1&5 T&L
7 Vv V 1&5 7T&11
8 Vv 1&5 7&1
9 y Vv 1&5 T&L
10 V V 1&5 T&I1
in Vv y V 1&5 7&1
12 Vv 2 8
13 Vv Vv 2 8
4 V V 2 8
15 V V V 2 8
16 Then V V 1&5 T&M
17 y Then ¥ v 1&5 7&1
18 V Then ¥ qv 1&5 7&ll
20 V Then ¥ 2 8
21 V ¥ Then V 2 8
22 V v Then V 2 8
23 Vv V V Then ¥ 2 8
Shaded lines represent System States not expected to be reported within the Network
Banking report set
© 2002 Fujitsu Services Ltd COMMERCIAL IN CONFIDENCE Page 24 of I
Fujitsu Services
Management
Network Banking Reconciliation & Incident
COMMERCIAL IN CONFIDENCE
FUJ00120468
FUJ00120468
Ref: NB/PRO/002
Version: 3.0
Date: 10/05/ 02
6.2 Exception States
This table identifies the NB102 series report section where an exception is reported in
detail.
Exception Description Exception report NB102
State Section
Uncleared Cleared
EOL IAdditional C112 1&5 7&il
E02 Additional C12 1&5 7&1
E03 IAdditional D 2 8
E04 Additional C4 1&5 7&1
E05 IAdditional S 1&5 7&il
E06 S after C4 1&5 7&1
E07 after D 2 8
E08 (C4 after D 2 8
E09 [D after C4 2 8
E10 (C112 after final state 1&5 7&1
Ell (C12 after final state 1&5 7&il
El2 (C4 after final state 1&5 7&1
E13 D after final state 2 8
El4 afier final state 1&5 7T&11
E15 lot Used
El6 lot Used
El7 lot Used
E18 lot Used
E19 lot Used
E20 [Amount of C112#C12 1&5 7&ll
E21 Amount of C112#C4 1&5 7&il
B22 [Amount of C112#S & C112#0 1&5 7&1
E23 Amount of C12#C4 1&5 7&1
E24 IAmount of C12#S & C12#0 1&5 7&1
E25 [Amount of C112#D. 2 8
E26 [Amount of C12#D 2 8
E27 __ Incomplete/corrupt C112 3 9
E28 IIncomplete/corrupt C12 3 9
E29 __IIncomplete/corrupt C4 3 9
E30 Incomplete/corrupt D 3 9
E31 [Incomplete/corrupt S 3 9
E32 IAmount of C4#S & C4#0. 1&5 7&11
E33 IAmount of D#S 2 8
E34 (C112 arrived after state F99 1&5 7T&ll
E35 (C12 arrived after state F99 1&5 7&1
E36 (C4 arrived afier state F99 1&5 7&ill
E37 D arrived after state F99 2 8
E38 S arrived after state F99 1&5 FERAL
E39 Settlement Date # Reconciliation Date 4 10
Shaded lines represent System States not expected to be reported within the Network Banking
report set
© 2002 Fujitsu Services Lid
COMMERCIAL IN CONFIDENCE
Page 25 of 1