Transaction management is crucial to the success of financial firms. The design and development of systems to support the firm's business operations is difficult, expensive, time-consuming, and risky.

Eclipse specializes in such systems. Over the years we have developed an architectural approach that has proven itself successful in a wide variety of situations. To us "successful" means:

• It must support real-world events. If through human error a transaction has to be cancelled post-settlement, the architecture must support it without requiring great effort on the part of either the users or Information Technology. The architecture must support the users, not thwart them.
• It must be controllable. The users must be able to control what functions can be performed. A powerful architecture is not enough; the power must controlled.
• The architecture must be extendable without significant re-programming. Scope discusses the area over which the architecture has been applied.
• It must be maintainable.
• There must be a high degree of transparency. This leads to a knowledge-based approach and to data structures that represent events explicitly.
• It must be reconcilable. The users should always understand why the system has behaved as it has and why the results are as they appear.

We present this best practices architecture here for two reasons:

• As a guide to implementing application systems. We discuss here the basic ideas that those designing and developing systems will have to consider.
• As a framework for discussing application requirements and approaches. Though the architecture evolved over a series of implementations, we have found that its structure and organization provides a useful means for understanding and validating requirements and for evaluating implementation approaches.

Though a number of models are described, they were developed after the fact, once experience had been gained through production use. Our focus is on what has proven successful, not developing domain models.

Audience

This material is directed towards those who work in the securities industry for firms such as broker/dealers, investment banks, and hedge funds. It may also be relevant to firms which have significant securities positions, such as pension funds and insurance companies.

The primary audience for this material is application developers in Information Technology (IT), those responsible for understanding the business requirements and then designing, implementing, and supporting systems to meet those requirements. The material may also be of interest to those who on the business side who work in Operations, Accounting, Stock Record, or similar departments.

We assume a fairly high degree of familiarity with the business. We discuss a number of useful references in the Links area of the site.

Scope

The scope of the transaction management architecture is defined in terms of the products, operations, and functions it supports. We discuss each of those areas in this section.

Breadth

The types of business, the breadth of the Scope, is very wide. It includes trading in a variety of securities, both on a proprietary and agency basis. It includes financing activities such repurchase agreements and bank loans.

In addition to trading, we also address loan-based activity such as bid notes, medium-term loan syndications, and commercial loan facilities. See Investment Products for some of the business types the architecture has been applied to.

Depth

Discussions can be at various levels of depth, with the highest level typically oriented around straightforward transactions such as Buys and Sells.

As we are looking at IT implementations, we go much deeper. We address:

• Supporting transactions such as bonds maturing, calls and conversions, and expirations and assignments.
• All forms of settlement, including netting and pair-offs, fails (full and partial), wires, and free delivers.
• Operational events such as cancellations and corrections, regardless of where they occur in the processing cycle (such as post-settlement corrections).
• Related events such as coupon payments and dividends.
• Bookkeeping entries.

This level of depth can not be avoided if the focus is on implementation. For instance, an algorithm to calculate trading P&L, one that you can actually implement, can not be described without it.

Transaction Types has a small subset of the events and operations we cover.

Range

Securities firms conduct a wide range of activities, from research, marketing and sales, through trading, to clearance, settlement, and accounting. Our scope addresses the portion of the range starting with order entry and going through trading to final accounting. The architecture was not developed for the earlier activities such as research or analysis.

We do not address margin, compliance, or regulatory activities here, though the architecture has been used for those purposes.

An indication of the range can be gained from Processing Functions.

Getting Started

Start with the Site Info page. It has an Architecture Road Map which lays out the components of the architecture, as well as a Learning Guide that presents a recommended order for viewing the pages.

We suggest that you take a few minutes to review the primary references. We identify a number that we consider indispensable.

The transaction management architecture itself comprises two areas, which are discussed in detail in the links below:

• Functional Framework. This area addresses the application-specific components of the architecture, such as transaction processing, P&L, positions and balances, and the underlying data structures.
• Technical Foundation. Key parts of the architecture are the design decisions and underlying infrastructure that support the functional framework. Understanding, adapting, and extending them are discussed in this area.

We are very interested in any feedback you have, questions, comments, comments, or criticisms! Please do not hesitate to contact us.

Copyright 2005-2021, Eclipse Software, Inc (ESI).  E-mail: WebSite@eclipsesoftware.biz.