Financial information systems

From a transaction request to a portfolio position

Client portfolios and financial scenarios / 2003 · transaction records and modelling

In 2003 I.V.A. worked on two portfolio management problems. CTSManager tracked a client’s requests and posted transactions. The REPO design explored how a different sequence of transactions would change cash flows.

From the company archive

A manager’s workstation, securities transaction tickets, a client portfolio and alternative transaction schedules. — Posted transactions form the client’s portfolio, while a scenario explores a possible sequence of operations.

How a ticket was posted

A transaction request in CTSManager was called a ticket. It specified the operation, securities, settlement terms and collateral. A manager first prepared the ticket. A member of staff then confirmed execution or cancelled the request in the Control view. Posted tickets appeared in the Portfolio view, where actual fees could be entered. This kept a proposed purchase distinct from its outcome.

Cash and collateral

A transaction depended on where and when cash would be available. CTSManager derived the client’s cash balance from flows across several accounts. The manager could see the combined payment schedule and its timing, alongside loans and pledged securities. This put the funding terms in the context of the transaction itself.

Remote client access

The remote application showed clients their account and portfolio. In protected mode an electronic key identified the client, who could submit a real request. Open mode let users try the same actions on a practice portfolio. XML files carried reference data, and access rights governed the exchange of personal records.

Scenarios in the REPO design

In the REPO design a user arranged purchases and sales of promissory notes on a timeline. Changing the term of one operation would recalculate the cash-flow schedule and the result for the whole scenario. A selected version could be saved as a separate file and sent to the centre. Protected monitoring was designed to return information about actual execution to the client.

Outcome

The work produced CTSManager version 1.0 and a REPO system concept with an operations model and interface design. The work in this area was formally accepted.

Portfolio, ticket and scenario

Reference data exchange and access to a personal portfolio in CTSManager.

Three modes in the REPO design connect a model, a selected plan and execution records.

The ticket form links transaction terms to promissory note details and settlement instructions.

REPO interface design showing the start and end of operations on a timeline.

Project in the timeline

2003

Development of the РЕПО information system for organising and managing financial transactions (КТС)

Tell us about your project.

Discuss a project