FUJ00087187 - Transaction Corrections within Riposte based Horizon

Evidence on official site

FUJ00087187

FUJ00087187

Transaction Corrections within Riposte based Horizon

The ‘Old’ Horizon system (pre HNGX) was based upon a product called Riposte. The basic
architecture was that each counter had a local database known as a Message store. The data centre
had a number of servers known as Correspondence servers, each instance of which managed a
subset of the live branch estate.

Correspondence servers contained large Message stores which replicated to and from the set of
counters that Correspondence server managed. Thus collectively the central Message stores would
contain detail of all branch transactions.

The old Audit system harvested branch transaction data from the Correspondence servers giving it
an audit trail of all branch transactions.

The replication process between the Correspondence server message stores and counter message
stores was 2-way. So it was possible to inject messages into the central message stores and these
would be transmitted to the relevant counter message store. This was the process that was used to
effect the equivalent of transaction corrections in old Horizon.

Any such correction entered this was would be recorded with a node Id of the central
correspondence server (> 32) and would be included in the standard branch audit trail. Thus they
are readily identifiable. Though the same technique was used to transmit other data (e.g. Ref data,
and real time banking messages) from the centre to branch.

Any such correction would have been subject of an OCP (Operati

me old OCPS and some vi

* This technique would typically be used as a last resort to resolve an operational problem
* POL would sign off any OCP so would be aware of how an issue was being resolved
* POL would be responsible for communication any such action with the Post Master

As mentioned above, if this technique was used to resolve an in branch issue, then providing we still
hold the audit data for the period in question the ‘corrected’ data would be available in the branch
audit trail.

Unlike the current Transaction Correction tool which restricts the types of corrections that can be
made, it was previously possible to inject any sorts of messages into the branch transaction stream.

Alan Holmes

Based upon a conversation with Gareth Jenkins

12 Aug 2016