HNG-X Counter Application Review +. _9" February 2010
RMGA HNG-X Counter Application Review “
w of the of. Xx lication relating c:
transactions at the Counter
Circulation: Alan D’Alvarez, HNG-X Programme Manager
Graham Allen, HNG-X Applications Engineering Manager
Andy Thomas, HNG-X Counter Architect
David Johns, Lead HNG-X Architect
Maz Kostuch, Director of Service Delivery and Projects, PSD
David Leask, Managing Customer Solution Architect, PSD
Authors: Paul Roberts, Applications Architect, AS
Stuart Rye, Managing Consultant, PSD
1 Introduction
1.1 Terms of Reference
Following the occurrence of a transaction being duplicated on the HNG-X Branch database, Stuart
Rye and Paul Roberts were asked to review the Counter Application architecture and design and
ensure that it fully supports the.need to protect the integrity of financial transactions.
The scope is focused on the integrity of the Counter Application in retation to financial transactions
captured at the Counter. It does not extend to data migration or other transient issues caused by the
‘switch from Horizon to HNG-X.
1.2 Background
The objective of HNG-X programme is to develop a system with structural and operational
characteristics that substantially reduce ongoing support and maintenance.costs with respect to the ”
current Horizon system. A key component of HNG-X is the Counter Application. In contrast to the
Horizon Counter Application, the HNG-X version retains operational data (e.g. Reference Data) and
business logic, but transactional information is stored directly in the Data Centre. The Counter side of
the new applications is based principally on Java technology. The Counter hardware is reused from
Horizon with the initial migration deploying the new application on the existing Windows NT 4.0
operating system. Where it has been feasible to reuse components from the existing Horizon Counter,
these have been carried forward into HNG-X
process detected an error in a banking transaction Subsequent investigations revealed that the
Branch database had two transactions with different JSN’s but the same SSN’ for a specific Counter
on that day but the 3 Party banking system only had one transaction. The clerk did not know that a
duplicate transaction had been created
An analysis of the database has revealed one other occurrence, again at Derby but on a different day
and involving a different clerk. This had not been detected by the DRS as it did not contain a banking
component and there is no other business reconciliation which might have spotted it. I disagree. My
understanding is that the other example was also Banking and also picked up by DRS. Email from
Claire Drake on 28/1 refers. First incident was a Deposit and the second was a Withdrawal, _
The net effect would be that the Post Office and the Branch records would not match. Where this
happens, the Post Office investigates the branch and Postmaster, with a view to retraining
or even
uncovering fraud. It would seriously undermine Post Office credibility and possibly historic cases if it
I JSN - Journal Sequence Number ~ Used for audit purposes and must be unique without gaps per each Counter.
? SSN — Session Sequence Number — Unique within the session and can be duplicated after a period of time
Page 1 of 14
Version 1.0
- (Deleted:
FUJ00172031
FUJ00172031
{Comment [DL2}: I suspect
that there was a
misunderstanding here. I
believe that we told them that
both were:banking related and
picked up by the DRS, however
we pointed out that theoretically
the same error on a pure stock
‘sale would not be picked.up by
the DRS or any other data
centre reconciliation system.
HNG-X Counter Application Review
9” February 2010
could be shown that a discrepancy’could be caused by a system error rather than postmaster/clerk
action. Most importantly, the central database as the system of record would be called into question.
The new Counter Application records all financial transaction data in the Data Centre. The PC in the
Branch runs the Counter Application (with other sub system components). It is critical that the central
database properly records the actions at the Counter and reliably reflects the actions of the clerk.
There was a suggestion that the running of performance monitoring software in Derby created the
conditions which triggered the failure._Hasn’t that now been discounted? The development team
concluded the failure was caused by a bug and a resolution has been identified which includes further
measures to remove the possibility of this occurring in the future.
The Counter development team were able to recreate the Derby error by heavily loading the processor
in a terminal and double keying the “settlement” action.
Further assurance is required that Fujitsu has got to the root cause and there are no other potential
issues with the integrity of the HNG-X as a system of record.
13
Approach to assurance
Paul Roberts and Stuart Rye, joined the HNGX team on Thursday 4" February. We met with the
following people
David Johns — Lead architect - 4 hours
Andy Thomas — Counter architect — 6 hours
Steve Porter — Counter development team — specific questions
The following documents were provided:
HNG-X_Solution_Architecture_Overview_2009-07-28.ppt
ARCSOLARCO0001_v4.1_Draft Overall Solution Architecture.doc
ARCAPPARC0003 Counter Architecture.doc
ARCAPPARC0009 Counter Business Architecture.doc
REQCUSSTG0002 Branch Exception Handling Strategy.doc
DESAPPIFS0012 BAL Service Interface Specification.doc
Our approach was to:
Understand the business process — from the Counter to back end / 3° parties
Understand the business risks and controls
Understand the system architecture, risks and controls
Explore the specific failure in Derby and its resolution
Explore any other areas of risk where the Post Office and Branch could end up with a variance
due to a system error.
The review was conducted with the assumption that the HNG-X system was a technology upgrade
and not a business process reengineering project. Business requirements and controls in HNG-X
should be the same as the current Horizon platform. It was declared that the Counter Application has
been re-written based on Business specifications provided by the Post Office since the Horizon
Counter Application had been developed using a third party product.
2
24
Findings
General
The HNG-X system does represent a technolagy migration, with no material changes in business
function. However, the development team involved in the Counter Application was intentionally
drawn from people with no familiarity of the current platform, partly because the skills base is
different and partly due to the fact the Horizon Counter Application had been developed using a
Page 2 of 14
Version 1.0
FUJ00172031
FUJ00172031
FUJ00172031
FUJ00172031
HNG-X Counter Application Review 9" February 2010
third party product which would not feature in the HNG-x solution.._Was this really intentional? J .
There was some overlap (eq Walter andme!)) _ 27] Comment [DL2]: I believe
that this comment originiated
from myself and has been
overstated in the above.
© There are no material changes to business function._There were some in specific areas, but in
general this was the aim. However, the adoption ofa real time transactional system has However it is stil true that we
increased traffic to and from the remote database and therefore the process time. Time at the did not go out to maximise the
counter is critical to the Post Office so a decision was made to find efficiencies where possible. In transfer of business knowledge
particular, the settlement process for cash only payment was improved, with the removal of an through. use of the team with
the i be skill
.extra button press previously required to complete settlement._POL also took the opportunity to ———~—_ v/v
make simple process changes, but in general things were pretty much the same.
2.2 Business Process (see Appendices)
The business process is essentially the capture and settlement of a complex retail shopping
transaction. Customers can, inter alia, purchase stamps, top-up prepayment keys (I don't think we
their basket with a range of methods — cash, vouchers, cards.
The clerk logs the customer's transactions in a basket (just like online shopping). These could be
a mix of all types of transactions. Each basket has an identifier called an SSN assigned when the
basket is opened. These are specific to the Counter and basket but not unique as the SSN is
* Once complete, payment is taken for relevant items and/or cash paid o out for a withdrawal and the
basket settled i.e. recorded on the central database and flushed from the Counter. Each basket at
the database is assigned a unique and auditable reference called a JSN. Not quite correct. A
JSN is assigned to any auditable data that is ied at the data cer Baskets represent
90%+ of these. SSNs only relate to baskets so SSNs may have gaps, but JSNs shouldn't.
«Card (banking) transactions are pre-authorised with the issuing bank when the card is presented
Authorisation is a pre-requisite to the basket being settled. A unique identifier is generated for the
banking transaction at the point of the authorisation request. If authorisation fails, the basket
remains unsettled and the customer must abandon the withdrawal or settle another way. Banking
withdrawal and settlement are different things and this is confusing the two. (but it probably
doesn't _- {Comment [D13}; I. believe
oesnitmattee eee eee eee ~~” I that it dées matter especially in
* Accumulated banking transactions are settled as a batch process at the end of the day, based on cranial The POL Benkrg
the baskets recorded as settled on the database. This is the Data Reconciliation Service. DRS transactions (as opposed to
reconciles, Banking, Plastic and ETU not just banking, Note that DRS doesn't do the settlement — card payments) are always a
hat is done by POL. Wh is reconcile the Counter and Bank views of what transactions dificult concept to understand
have occurred. by other IT professionals with a
a pure.retail background.
However it is important:to POL
2.3 Settlement that this review was undertaken:
by people with a good
understanding of the solution,
The clerk indicates the transaction is settled in two Ways: “Fast Cash” and “Settle”. There is a button
for each. Each triggers a process resulting in the basket being logged on the database.
*° Fast Cash
“Fast Cash’ in that the clerk has only one key to press. They can do this when the
transaction is settled by cash only '
© This places an entry for the cash amount in the basket which sets the total to nil and the
basket settles.
° Settle
o The clerk uses “settle” to bring up a menu of settlement options where the customer is
paying by means other than cash only. The clerk records the relevant settlement methods
and amounts. Each amount is logged in the basket. Once the basket reaches “nil”, the
basket settles.
co Ifthe basket is already “nil”, the “settle” button goes straight to settlement.
When the basket settles, the Counter confirms with the Branch database that the basket is set to “nil”
ie. all payment received / cash paid out. On receipt of confirmation from the database that the basket
has been properly captured and committed, the process of flushing the basket is started. In some
Page 3 of 14 Version 1.0
HNG-X Counter Application Review 9" February 2010
cases a receipt is printed and cached based onthe basket details before it is flushed, in others the
receipt is cached (usually for a banking only transaction, where the receipt is printed at the point of
authorisation and no other items are present). Once these procedures are complete, the basket is
flushed
24 Reversal Settlement
This occurs when a customer returns due to some error being made. For example, I bought 2™ class
‘stamps but I needed 1" class-stamps or the customer was bought and/or sold the wrong item.
There are two different reversals that can be performed:
© Customer returns with receipt within a specific time window
© This initiates a reversal settlement process and is referred to as an “existing reversal”. The
process inserts a “reserve” transaction on the database before settling the reversal. The
Clerk is guided through the reversal process and there should be no opportunity for a
double settlement to occur. By “double settlement”, I assume what is meant is that the
same transaction can be reversed more than once, ER: e standard basket
technology and so also have the same controls as normal settlement.
* Customer returns without receipt or with receipt outside the specific time window
© This will follow the same process as for a normal settlement and is known as a “new
reversal’. The financial amounts will be a different polarity. This process is protected by
the same controls as for a normal settlement.
2.5 Controls
© Control over the data capture process (for example, disabling input from peripherals such as the
touch screen, bar code, scales etc.) is supposed to be maintained and integrity provided by
ensuring the clerk or peripherals cannot initiate out of sequence events. (This control failed in
Derby.)
Banking transactions have an end of day control run by the DRS which reconciles the intra-day
authorisations with the end of day settlement. This will alert duplicate or missing entries. Banking
transactions have a unique identifier. These cannot be duplicated (except by bugs!).
* Allother financially relevant 3” party interfaces (in particular Moneygram) have business logic built
into the process to prevent duplication or a loss of a transaction. With Moneygram, the clerk is
forced to acknowledge the point of financial settlement in the process and there is a specific input
button presented after this point to commit the funds. There is no opportunity for this to be
repeated or initiated by any other means.
+ The JSN has a uniqueness constraint as it is used for auditing purposes. It is dlso “dense”
meaning that there should be no gaps for a given Counter. It is valid for a Counter to send
transactions with a duplicate JSN, for example during a retry process. In this scenario, if the
transaction is already stored in the Branch database, it will fail on the uniqueness constraint which
will force a comparison of the transaction to be stored and the transaction already stored. If they
are the same, the to-be stored transaction is discarded. A discrepancy in the transactions will
force an error to be raised and the Counter will be logged off.
which clears the basket of non-1 recoverable Se lane
2.6 Spotting the duplicate Derby basket
+ Itwas the end of day reconciliation of the banking transaction in the DRS that alerted Fujitsu to a
problem. Transaction settlement requests were presented for two transactions with the same
unique transaction identifier and the second one was rejected. This revealed the presence on the
HNG-X database of two duplicate, absolutely identical baskets with the same SSN and contents
but different JSNs. Essentially, the Counter had submitted the same basket twice to the Branch
database which had logged each as unique, with different assigned JSNs. Pre-authorisation only
happened once as'this took place before the basket was settled.
Page 4 of 14 Version 1.0
FUJ00172031
FUJ00172031
- (Deleted: transactions
- (Deleted: transaction
HNG-X Counter Application Review 9" February 2010
2.7 Cause of the duplicate basket
* Inthe old Horizon system, the clerk was required to press “Fast Cash” and then “Settle” to settle.
In the new system, they only need to press "Fast Cash”
¢ In Derby, the clerks concerned adopted the old procedure and pressed “fast cash” (which
recorded the cash entry, set the basket total to “nil” and initiated the settlement process) and then
“settle”. The settle button should not have been enabled but it was. As the basket was now at
“nil”, the basket was settled again immediately.
There is nothing particular about Derby. The performance monitoring was not running,
2.8 The Resolution
The development team have implemented an immediate resolution within the Counter Application
and are considering possible solutions involving the Branch database (see Appendices for
process flows)
* The Counter Application:
o It was discovered that the peripheral input iock was released before the basket was
flushed and the “Settle” button enabled. This allowed the clerk to activate the “Settle”
button. and because the basket was already set to nil, it was sent to the Branch database
and caused the duplicate. The ability to press the “Settle” button was due to timing
differences. The clerk was very efficient and following the old Horizon process. Windows
was servicing another process. The Counter Application code has now been modified to
flush the basket before the peripheral input lock has been released. Isn't this the same as
the next bullet?
© The development team also found another scenario when this could occur and as well as
correcting this they have implemented additional code that highlights any further scenarios
that have not been discovered. The additional code ensures that the Counter Application
is in "Busy Wait” state at the point the transaction is sent to the Branch database. The
code does this irrespective of whether the state is already correct. If the state is not
correct it produces an alert message on the Counter Application. This has only been
adopted for the Development and Test environments
© A’“flag" has been added to the basket that prevents duplicate settlement initiation. This is
a belts and braces approach since the previous code changes should not require this
functionality.
* The database solutions:
The solutions being considered are:
© Check for duplicate SSN on receipt of a basket. If this is done real time, it will place a
demanding overhead on the database.
o Check for duplicate SSNs as part of an audit process during the overnight period.
2.9 Stock check
* Stock checks will highlight differences between the Post Office records and Branch records.
Some post offices undertake daily checks, others weekly, others rarely._They are all supposed to
check their Cash Daily (though not necessarily to Compare it against the system figures). They
must check Cash and stamps whenever th lance which is at least once per month. I agree
that other stock may be rarely checked. .
3 Conclusions
Overall, the actions taken to redress the Derby issue are appropriate. We believe the Counter
Application fully supports the need to protect the integrity of financial transactions.
Specific conclusions are detailed below.
Page 5 of 14 Version 1.0
FUJ00172031
FUJ00172031
HNG-X Counter Application Review 9" February 2010
3.4
3.2
3.3
34
3.5
3.6
37
38
39
3.10
3.11
3.12
3.13
3.14
3.15
3.16
Business controls for banking transactions will alert duplicate baskets containing banking
transactions because of reconciliation checks in the DRS but there has not been a control for
baskets with no banking transaction — this is now being addressed.
Duplicate banking transactions with different identifiers cannot be created.
The duplicate could have happened anywhere, not just Derby; (performance monitoring not
enabled). .
Baskets cannot be ‘lost’. The JSN and associated checks provide confirmation that all
transactions sent from the Counter are stored in the Branch database. Recovery procedures
built into the Counter Application and Business Processes ensure transactions are not lost.
Duplicate baskets cannot be created in the Counter Application and cannot be submitted to the
database more than once following the resolution taken by the development team. This was
less of a risk in the old technology but an increased risk with the adoption of the centralised
financial transaction approach and the real-time transmission to the database from the Counter
Application:
The business control at the Counter recognises that dual settlement risk is inherent by having
two buttons that can initiate settlement. The business requirement is that the buttons operate
on an exclusive basis — i.e. the use of one disables the other. The implementation in the HNG-
X Counter Application failed and enabled both buttons to be pressed. They are not exclusive
Once you're on the Settlement menu you should be able to invoke Fast cash again. Also once
in settlement you can add an item and so need to be able to Settle again, so the buttons is not
an issue. It is the enablement of them during settlement that is the fault,
The Counter Application design did not have sufficient controls to prevent duplicate basket
transmission (regardless of the control intended to limit initiation of settlement by different
buttons).
The peripheral input lock release occurred too soon in the process, and allowed “Settle” button
to be pressed
The Counter Application fix adopts a belt and braces approach and is very strong.
The design of the basket flag control is a good one
The basket submission flag avoids the timing trap that the “Settle” button lock fell into and is
enabled at the correct point in the process, just before the transmission to the Branch database.
A basket cannot be flushed until confirmation is received that it has been properly committed
and logged at the database
The design for the basket flag allows for the flag to be correctly removed if a card transaction
fails, allowing an alternative settlement method to be adopted. _I didn't think the flag was set
FUJ00172031
FUJ00172031
when a card authorisation was carried out — only when actually settling a basket,
An SSN is associated with a basket. Per Counter, per day it can be used.as check for
duplication (within a population of 1 million) *
Given the strength of the implemented Counter Application controls a real-time check at the
database for duplicate SSN receipt should not be necessary and would potentially decrease
performance of the system
An end of day procedure to detect duplicate SSN is acceptable. We are not planning to do this
Page 6 of 14 Version 1.0
_ {Comment [DL4}: 1 think this is
the mechanism by which we will
implement’3.1 above. I believe
that we do need to put this
mechanism in piace on a
Permanent basis, but do not
know if;development have
committed to do this.
FUJ00172031
FUJ00172031
HNG-X Counter Application Review 9" February 2010 .
3.17 The “new reversal’ process follows the settlement process but the transaction amounts have a
different polarity. The ‘existing reversal" process is a guided process and the clerk does not
have the opportunity to create duplicate transactions. Again not sure I follow this,
* 3.18 Other interactions do not create risk, e.g. post code look up, or have appropriate business and
technical controls’in place
3.19 It is unsure what testing has been performed to prove peripherals are disabled and enabled at
the correct point in the Business Process.
3.20 Stock check is not a reliable method for catching issues due to the erratic nature of the stock
check occurring. Cash checking might be, but cash is usually slightly wrong due to human error.
3.21. The Counter Application is quirky when ordering quantities of stamps. For example, it is
possible for five stamps to be recorded as one stamp if the clerk does not interact with the
Counter Application correctly.
3.22 There is no practical control to stop under and overcharging for baskets caused by clerk error.
For example, the clerk my give the wrong number or denomination of stamps
3.23 There seems to be no other risk of baskets undercharging.
3.24 There is a solution to detect incorrect busy-wait states in the development and test environment
which would be useful, with enhancement, in the live environment as an indicator of failing code.
4 Recommendations
4.1 The “busy wait” check should be implemented in the Production environment but with an Error
message being written the Windows Event log in preference to the Alert message. This Error
message would be transmitted to the central database following the business as usual
processes for detecting errors on the Counter PC and appropriate procedures put in place
4.2 Do not implement the'real time duplicate SSN check. Create an audit report for SSN duplicates
with the same JSN on same day. This could be run on the Disaster Recovery database if
performance is an issue._I think they mean BRSS rather than Standby database. However we
need to get that working first! .
4.3 Review peripheral disablement and enablement testing and where appropriate undertake more
testing for specific use cases to check peripherals are in the correct state.
_ I Comment [DL5]: I am not
‘sure where this check is
intended to be made. I
: - recommend that we incorporate
45 Consider advising the Post Office of the benefit of more effective stock control as.an indicator of a check within the ARQ process
clerk errors or Fraud. before supplying audit data to
POL. This check may cover the
4.6 Review and strengthen negative testing, if appropriate. The recent problems reflect the pomniaiy any omer suptcation
asynchronous nature of the new application and traditional or historic test cases may not reflect / uniqueness issues that can be
this. detected.
4.4 Check for duplicate SSN before raising discrepancies with a Postmaster) .
Page 7 of 14 Version 1.0
FUJ00172031
FUJ00172031
. HNG-X Counter Application Review ~ 4" February 2010
Appéndices High Level Business Flows : -
2" diagram is missing the need to invoke Fast cash / Settle, Also the basket Balance in the 2md diagram should be £100. This is __- - (Formatted: Font: Not Bold __}
the area where the report authors confuse Cash Withdrawal with Card Payment. It is important to correct this or remove the
diagrams.
‘I Formatted: Font: Not Bold,
. . Superscript
1. Business Process - Formatted: Font: Not Bold
No banking transaction -
Mon £100 Moneygram £100
ela sla Vciass samps £30
Pensesiatea £10 rps £10
Balance zo a
L_ [rnorese une
a HG database
Card, che
basket
‘Mone e
= em 100
$Y class stamps £30
2M eass stamps £10
Cash recnived £40
‘Cheque recived £100
Balance £0
2. Business Process -
Banking transaction
Cash withdrawal £100
‘Automatic update
HINGX database
FUJ00172031
FUJ00172031
HNG-X Counter Application Review 4" February 2010
~System Flows-BankingTransaction-OK 5 eee __.»~ (Formatted: Font: Not Bold)
I don’t think this is correct (as with previous diagram) It looks more like settlement of a basket via cad payment than a Banking = _-- (Formatted: Font: Not Bold)
transaction.
Also in the case of card payments, the settlement model is different and is based on the settlement transaction. The payment file
for Streamline is created from the settlement transaction loaded into DRS.
{am not sure whether the DRS check for a duplicate transaction would have prevented the system from putting 2 transactions in the —
payment file. Hence in this case the duplicate transaction could potentially have been passed to Streamline — but if so I assume that
it would have been rejected there due to 2 payment requests forthe same authorisation?, ee _ ~~ -[ Formatted: Font: Not Bold
Page 9 of 14
HNG-X Counter Application Review
4” February 2010
Chip and Pin Payment Transaction
Peroneral input Lock
oleaved
+ TZ];
Te] conet 77
5 7 Sa 7380]/ empty-
sI. j a]: rot
z od =
8 ‘Al Peipheral
Input eked
Autereaton
Roques:
Z
z
ES
ORS Reconeiaton Senco Feoxctaon I
Reon
2 —— M
5
é
2 Racoriiation OK ~ a
o trasactors meich
Page 10 of 14
FUJ00172031
FUJ00172031
HNG-X Counter Application Review,
4" February 2010
System Flows - Banking Transaction - Comms Failure
I Again not correct
Chip;and Pin Payment Transaction — Comms Failure.
TER] I earonaranout ack Relasod
. [See] Clerk Garces and eer reres
A aca 7.8.91) CePor aiteren payment mehod
8 anpecgharn
Input Licked
Authorisation
aguas ls rot roceived by ,
‘3 Party 0 response is Branch ‘
: Not eceved by the Courier oaasae I)
z Possible no respons varveien
Teaming Tansscinsy
DRS Reconelation Senice
> - —
2
5
&
z
ta
the Beaneh database
FUJ00172031
FUJ00172031
_-~ (Formatted: Font: Not Bold
Page 11 of 14
FUJ00172031
FUJ00172031
HNG-X Counter Application Review 4" February 2010
Formatted: Font:.Not Bold
System Flows - Banking Transaction — Cash Transaction :
I This applies equally to a stock transaction settled to cash rather than limited toabanking transaction, = =
Cash Payment Transaction ° SS
Peroner! Input Lock
Released
. Jaco 2g) sesvertut //
8
=
3 Alara
oO Input Locked
Stor wransaction
z
a
2 ~
5
e
%
Page 12 of 14
HNG-X Counter Application Review
4" February 2010.
System Flows — Derby Issue
Banking Transaction — Derby Issue
let parker ban Basket bitanced £0.40
(le prrms banking eed 9 selec setlement
, [Fespons ai // - eT
< . fi
3 ‘AN Peripheral [~~
° (rout Locked A} Peipperal Parga Lock
n H ‘put Locked etch
rocoxe I
—— ‘Store basket again
‘Store transaction l
OK
Beating Taesacion ]
BrorcnOaatace II
2
=< £15trensadion [7 £15 transadion JT
a ‘JSNi123, SSN:456 I I JSN:124, SSN456 J I
Response ]
. rng Toemctone—T Sting Tans -
(ORS Reconctiion Service
> 3 Party a ————
2 atabae
é os acronis
Bo crwosacon because 3" Paty ony has
‘one £15 wangoction
Page 13 of 14
FUJ00172031
FUJ00172031
FUJ00172031
FUJ00172031
HNG-X Counter Application Review 4" February 2010
System Flows — Derby Fix
Banking Transaction — Derby Fix
Clk perms banking Perigherl Input Lock “Tha key dsteroncos ae: .
Released I. lag on basket io sop second submission
) Teer J) 2 Peter! nou Lock Reese coir fer baskets
estat ut et seared down
S Response] J Fast Cash I a empty / 5 The BusyWaifuncson is execute belora
3 cong / as ‘Conn occurs. Tis i rogardies of
5 J} ——/ titer itwas Sready execusng Ii was rot executing
3 ‘A Padphoral fn Alerts gonerated a the OEV and TEST
i) {rput Locked trvronmerts, but tf recommended an ERROR shud
bo wation tothe Windows Event Log 0 can be
Receipt chched but ‘etocied atthe Data Centro
rot ited 41 Recommendation for a report to ok tor ransocions
wah same SSN, diMerentJSNS on the same day for he
‘Same courcar. This wil dare! dupleaa real only (no
. banking elamen) ransactions
Stora ransacton
OK.
anking Tesction .
Branch Database
3 £18 vansaction
JSNIT23, SSNASB
Response -
>
5
a] -
z
bd Reconciiation OK
Page 14 of 14