1999 the Cavendish Organisation Limited.Page 1

InterAct TradeLink

Table of Contents

WHITE PAPER

InterAct TradeLink:
Front- and Back-Office Integration
for Financial Institutions

©1999 The Cavendish Organisation Limited.Page 1

InterAct TradeLink

INDEX

Contents

Contents

Introduction

The need for automation

The trading environment

The role of middleware

Categorising middleware

InterAct TradeLink overview

TradeLink components

Operation flow

Initialisation

Error handling

System management

Configuring TradeLink

Security

Appendix A: Support for MKI's MIDAS

Host system support

MIDAS screens and trade types supported

Rates handling

General notes

INDEX

The information presented in this briefing paper is based on a family of products which are under continual development and enhancement. While Cavendish has endeavoured to ensure the information here accurately reflects the use, operation and specification of the InterAct products it addresses this cannot be guaranteed. We will be happy to discuss specific aspects of InterAct in the context of the current status of the product.

Introduction

InterAct is a family of related middleware products developed by Cavendish to ease the integration of diverse IT systems and to manage the flow of information between those systems, application software suites running on them and users of those systems.

InterAct TradeLink is an application based on InterAct Link, the family member which handles 'peer to peer' system integration (as opposed to, for instance, InterAct FreshLook which is designed for delivering new system front ends to users). TradeLink is designed specifically for financial institutions who need to integrate front-, middle- and back-office systems where the requirement is to minimise or eliminate the need for manual intervention in areas such as trade processing. Briefly, InterAct TradeLink offers:

• Automated deal re-entry into middle- and back-office systems;
• Store-and-forward processing of trade details;
• Identification and queuing of failed transactions;
• Reporting and audit facilities.

This white paper looks at InterAct TradeLink in some detail from a technical and functional perspective. It is aimed at the reader who has a good knowledge of the types of systems in use in the typical financial trading environment and of the business processes involved.

Being based on InterAct, the TradeLink framework is capable of handling almost any combination of front- and back-office systems. This white paper takes as a particular example the MIDAS™ system from Misys-Kapiti International (MKI) since this is one of the most widely used back-office systems in the areas where TradeLink is applicable. Support for MIDAS is covered in Appendix A on page 14.

The paper assumes that the reader is generally familiar with the concepts behind InterAct and the system's architecture. Information on these aspects can be found in various technical briefings and interactive media presentations, as well as on the InterAct website at

The need for automation

The trading environment

A typical financial trading environment depends on a mixture of computerised and manual processes. Firms have invested heavily over the years in sophisticated systems which support their dealers, handling the complexities of dealing in securities and other financial instruments. Usually to a lesser extent those same firms have implemented systems in the back office which take care of settlement, accounting, regulatory obligations and suchlike. Then there are other systems which are also essential to their business - risk management, customer and counterparty databases and so on.

Usually these systems have been implemented largely in isolation from one another: some using off-the-shelf packages, others bespoke solutions, still others a combination of standard and customised components. One thing is common: the systems share little resemblance from an architectural or technology standpoint, and are usually difficult to link to each other in a useful way so that information can flow smoothly between systems.

This is understandable: rarely do 'best of breed' systems come from one single source, and even less often do firms have the luxury (which itself is questionable) of being able to replace all their critical systems in one sweep, guaranteeing effective interworking as they do.

However, the trading process does need information to flow quickly, reliably and effectively from front office (the dealing desk) to the back office and elsewhere. Deals are entered by the dealer directly into the front-office dealing system, and then need to find their way to the back office for settlement, regulatory reporting and more. Too often this process needs manual deal re-entry into one or even several back-end systems. Periodically someone has to collect printed deal slips generated by the dealing system and then manually re-type these into, for instance, the settlement system - possibly routing different types of deal into different systems. The entry clerk will need to know how to transcribe a deal into a form suitable for the settlement system to handle, as it is quite likely that details such as counterparty codes, currency units and suchlike will differ between the two systems involved. Then there is the chance of human error: the likelihood of a miskey seriously affecting a deal over a trading day involving hundreds or thousands of individual deals is high, with a clear risk to the business.

The argument for automation is clear. The immediate benefit is the removal of the need for slow, expensive and error-prone manual data re-entry. This in itself is often sufficient justification for automation. Wider afield, there are significant advantages to the business in areas such as risk management, fraud detection, reconciliation and elsewhere.

However, to achieve this objective without upsetting the IT environment critical to the business needs careful thought. The criticality of these systems will often rule out major changes to them, or their wholesale replacement without compelling reasons which go beyond the need to integrate. Instead, often the best path is to exploit the existing systems and look for a way of sharing information amongst them with minimal impact to each system.

The role of middleware

Most systems are able to communicate with external systems via some sort of networking. Standards such as TCP/IPhave been around long enough to be widely supported by most operating systems and hardware platforms.

However, simply being able to make two diverse computer systems communicate with each other is not enough. This basic capability can normally be taken for granted: what often can't be is the ability of two diverse applications to communicate with each other at a high level. This requires a lot more than being able to get a byte of data from one system to the other. Each system needs to understand the nature of the information it is handling: the content of a transaction, and how a transaction is to be manipulated.

This is the role for which middleware is designed. Middleware is more than just a way of getting two different IT systems to talk to each other (though some so-called middleware products are just that). As well as basic intersystem communication, a middleware layer will be able to manage the high-level flow of information between two or more systems, taking care of aspects such as

• transaction mapping between different systems and business applications
• secure delivery of information from source to destination
• 1-to-1, 1-to-n and n-to-1 system to system information distribution
• error and failure handling and recovery

Categorising middleware

Middleware can be categorised in many different ways, with one of the more useful approaches being whether the application needs to understand the middleware, or vice versa. Middleware falling into the first category will need the application software on each target system to be configured to interwork with it. Into the second category falls Cavendish's InterAct middleware - here the middleware adapts to fit around the existing capability of the target systems and applications, a characteristic often referred to as non-invasive operation.

A comparison of different middleware technologies and architectures is inappropriate here (such comparisons can be found in other Cavendish material as well as from other sources). InterAct adopts a 'hub and spoke' architecture, with information flow being co-ordinated through a central server (a function which can be distributed across a number of physical servers). This approach has several advantages over alternative structures such as information buses due to its ease of management, centralised transaction handling and non-invasive nature (since there is no need for software components to be installed on co-operating host systems).

This is the architecture on which InterAct TradeLink is based, which we shall now move on to consider.

InterAct TradeLink overview

TradeLink components

InterAct TradeLink consists of two major components:

1. InterAct Link, which handles all communication with the surrounding front- and back-office systems, and
2. The TradeLink application, and InterAct application which takes care of transaction mapping, store-and-forward processing, error trapping and management and reporting.

The architecture of InterAct TradeLink is shown below.

This example considers the straightforward situation where there are just two systems involved - a front-office dealing system () and a back-office settlement system (). It's assumed that these systems are running on separate and technologically diverse hardware platforms: this might be, say, a Digital VAX or Hewlett-Packard Unix system in the front office, and an IBM AS/400 or a mainframe in the back office.

In between these two systems is the InterAct Link server (). This can be based on a Windows NT or a Unix platform, and will use at least two physical systems for resilience purposes. For simplicity, we consider the server as one single 'logical' server for the purposes of this document (as indeed it appears to be to InterAct applications). The server is connected to the dealing and settlement systems via whatever type of link is convenient. Usually this will be some type of network, such as TCP/IP running over Ethernet.

The InterAct TradeLink application () is hosted on the InterAct Link server (though it can be run on a separate physical platform if preferred). It has no direct link with the surrounding front- and back-end systems - this is handled purely by InterAct, and, like any InterAct application, TradeLink does not need to know anything of the detail of communication with those systems.

The TradeLink application uses a local database to store transaction mapping tables and to hold its transaction queues. The database used is Microsoft's SQL Server. Usually this database will be mirrored, but as TradeLink uses ODBC to transact with the database this aspect is independent of TradeLink itself.

One of the roles of TradeLink is to provide optional ticket advices for deals passing through the system, and various reports which detail the system's operation and which are useful for audit purposes. This function () uses a standard report generator and can be customised.

Operation flow

Here we will take a complete cycle of InterAct TradeLink's operation, which illustrates how the system works and the operation of the various components summarised above.

Acquire a trade / TradeLink will use InterAct Link to connect to the front-office dealing system via a convenient existing access mechanism. For example, this could be a terminal session over TCP/IP(using telnet), a printer output stream or direct database access via ODBC. To do this TradeLink will open a data document, which will cause an InterAct script to run which transacts with the dealing system to acquire the next trade details. Exactly how it does this will be the responsibility of the script in question, which will be tailored for the individual front-end system and access mechanism.
Store the trade / TradeLink then stores the acquired trade in its local database. InterAct Link, since it uses the common InterAct architecture, will cache the data document containing the trade, but this is designed for transient data; TradeLink offers longer-term store and forward functionality for which it uses the services of the local database.
Map the trade / Having secured the incoming trade details, TradeLink will now use a combination of program logic and mapping tables held in its local database to convert the trade details into a format suitable for submission to the back-end settlement system. Any problems which are encountered in this process - for instance, an invalid counterparty code - will result in the trade being sent to TradeLink's error queue and will be notified to the system administrator.
Submit the trade / The final step is to submit the trade, once mapped into a suitable format, to the target back-end system (or perhaps to 'burst' the trade to more than one system). To do this, TradeLink opens another InterAct data document which relates to the back end system in question. As when the trade was acquired, will cause another InterAct script to run, which will deal with the appropriate mechanism to submit the trade. This might be, for instance, navigating through a series of menus on the host system to complete the transaction. Again, errors in submitting the trade are trapped and are passed back to TradeLink to be held in its error queue.
Produce ticket advice / Whether a trade is successfully transferred to the target system or not, a ticket advice is generated which details the trade and, if necessary, the reason why it was rejected by the back-office system.

The process then repeats for the next trade.

Many such 'loops' can be in operation at any given time, dependent on throughput requirements, the number of concurrent 'sessions' each participating system can support and the resources of the InterAct server platform. This is controlled by InterAct configuration: the TradeLink application and its associated InterAct scripts only have to handle a single loop process.

Initialisation

The TradeLink processing loop described above follows an initialisation phase while the system starts up. The front- and back-office systems taking part in this process will have some type of access control system. In the case of terminal-level access, this will be by means of login screens requiring a username and password for each system. For API-level access some type of security exchange will be necessary, and so on.

InterAct handles this via its standard access control subsystem. Before it can open and manipulate data documents, an InterAct application such as TradeLink will need to open a special form of the data document - the 'user' document - on each host system. This will use a set of user parameters stored within InterAct to login to each system, a process which will also then tell InterAct what level of access the user in question has to host resources.

Once successfully logged on to each system TradeLink is free to begin the loop processing described above.

Error handling

This is a vital consideration for any middleware solution aimed at automating front- and back-office integration. While the vast majority of trades will be processed with no problems, occasionally a trade will fail somewhere in the processing loop. This can be for various reasons including:

• The details in the incoming trade are incomplete (this might be expected to be trapped by the front-office system itself, but is still feasible);
• There might be an apparent replicated trade or missing trade in sequence;
• The trade might fail against the defined mapping rules and/or tables;
• The target system may be unavailable or crash in the process of handling a trade;
• There could be an error in communicating with either (or any) of the participating systems - this could be a communications breakdown, an application failure or a transaction failure (eg if a field in the submitted trade is rejected).

It is vital that any such failure is identified and managed properly. InterAct TradeLink does that by:

• identifying host communication and transaction failures within the scripts used to handle host transactions - trades are automatically resubmitted when the link becomes available again;
• trapping mapping errors within the TradeLink application;
• keeping track of expected sequence numbers to spot missing or duplicated trades.

In the event of any non-recoverable error the trade in question is routed to an error queue (held in TradeLink's local database) and a report generated to highlight the problem. Other forms of notification, such as email, would also be possible.

TradeLink's graphic interface allows the user to interrogate the system at any time to inspect failed transactions. The reason for failure will be seen, allowing corrective action to be taken. The user has the option to resubmit such transactions (if the failure was due, say, to some invalid code on the target system which was then corrected on that system). This interface is described more fully in the next section.

Commonly there is a need to be able to cancel a trade submitted to the back-office system in the event of some error being made on the front-end dealing system. In such an event a trade cancellation will be notified from the dealing system to TradeLink (usually in the form of a cancelled trade transaction, acquired in an identical fashion to ordinary trades). TradeLink then automatically correlates the original trade submitted to the back-office system with the cancellation request and submits a cancelled trade to the back-office system containing the back-office reference to the original trade.

In the current implementation of TradeLink there is deliberately no provision to repair a failed message within TradeLink for resubmission to the target system. This would be intrinsically a dangerous ability as one would not have the security of the originating application to validate the changes made, and would raise major audit questions. However, technically speaking and with that caveat, there is no reason why TradeLink could not support such a facility.