Working with Trade Creation

This section details the methods for trade creation in Temenos Transact.

Creating a Trade using SEC.TRADE

The basic SEC.TRADE transaction enables direct input to the system by the dealers who supply the key elements of the deal. The SEC.TRADE records both the buy and sell details of a transaction as well as allows more than one broker or counterpart and customer. Therefore, it is possible to perform multiple trade permutations as illustrated in the below table.

The example above is known as a bulk security trade as it comprises many individual trades using just a single transaction, which may involve numerous screens of input.

This facility allows the input of multiple purchases and sales on the same transaction and is particularly useful within a portfolio management operation, where a single purchase from or sale to a broker can contain an almost unlimited number of opposite customer sales or purchases. As Temenos Transact generates the accounting entries online, it facilitates the processing of large security transactions containing multiple transactions as a background process, thereby freeing up the terminal for other tasks.

Also, it is possible for the system to accept a basic transaction with a minimum input of ten items (post validation). For example, a basic transaction to record a purchase or sale of a security may require only the following information entered at the deal input stage. The basic fields to commit a trade are:

• Security
• Depository
• Customer
• Sell / Buy
• Nominal / Amount
• Price
• Broker
• Sell / Buy
• Nominal / Amount
• Price

It is also possible to have the trade price defaulted to the latest price held on the SECURITY.MASTER application. In common with other Temenos Transact business applications and indeed most of the securities application transactions, the usage of a special version enables the setting-up of user defined input screens. If the user knows that a field might receive a default, this field can be omitted from the display. Equally, other version records may be defined for transactions using brokers and customers with whom the user entity deals frequently. In the latter instance, these defaults are supplied by the version itself.

To ensure that Temenos Transact is able to provide as many accurate defaults as possible, it is in turn necessary to ensure that all the underlying information held in master files and other tables are kept complete and up-to-date as possible. For example, a portfolio customer may require that they finance their purchases out of one particular account, whereas the proceeds of any sales are credited to another. The capability for recording this sort of information exists in many different files within the Securities module and in some cases general files (those shared by other Temenos Transact modules).

The structure of the SEC.TRADE ID consists the following:

A common array of lead prefix (0-9, A-Z) excluding vowels are built-up. These lead prefix values are based on the session number depending upon the session number in the sequencing are shown below, where the bold letters indicates the lead prefix. Example - SCTRSC00335B0003.The initial details necessary to the record the security being transacted is shown in the below screen shot.

The no-input fields can indicate the choice the user made in an earlier field or display the defaulted or no-change system calculated amounts and so on. For example, the Security Ccy and Price Type fields are obtained from the SECURITY.MASTER application appertaining to the security that the user enters in the Security Code field. These assist the user during the completion of the remainder of the transaction and are an aid to ensure that the user has selected the correct security. The above example uses a Bond type Security, which happens to be non-interest bearing. However, had the transaction been an interest bearing security then the details such as Interest Rate and Interest Days must have indicated that the current interest rate and the number of days are elapsed as the last coupon date and the value date of the trade respectively. For share type transactions, interest is non-applicable.

Most of the information can be made to default although the user can always overtype an alternative permissible value. For example, the depository is defaulted from the underlying SECURITY.MASTER record, provided it is recorded within the Default Depository field in that application. This field allows input and the user can select a different depository if it is found necessary. This particular field advises Temenos Transact as to where theto where the bank requires the securities are to be delivered to or from where they are to be fetched.

The user cannot combine different depositories on the same transaction in respect of securities being delivered into or withdrawn from control by the organization. After advising Temenos Transact that the security is being transacted (mentioning the trade, value dates and depository) the user has to describe the customers’ details. In case, of a bulk security trade, it contains more than a single customer.

Updating the Customer Details

The fields related to customer information are described below:

Specifying Reallowance Rate

The Cu Reallowance field is used to specify the reallowance rate allowable against the price paid. Since this is a rate field, an entry is applicable for bond type instruments where the reallowance is calculated as a percentage of the nominal amount.Therefore, if the user prefers to grant a re-allowance with respect to a share-based transaction, the user may enter the re-allowance amount directly into the Cu Reallow Amt field immediately.

The Cu Reallowance field is special field that allows the user to enter the rate together with a leading - (minus) sign. Omitting the minus sign indicates that the user is granting an allowance, therefore, reducing the amount that the customer has to pay for his securities. If the user does not enter the minus sign, Temenos Transact adds the calculated re-allowance to the amount that the customer has to pay.

The entry of a rate in the Cu Reallowance field causes the system to calculate the re-allowance amount automatically. This is displayed in the Cu Reallow Amt field. If the user does not require a re-allowance amount, there is no defaulting and so the user must continue to the Customer Interest Amount field.

Defining Customer Interest amount

This field displays a value only if the underlying security is an interest-bearing instrument. In this case, validating the record causes Temenos Transact to default the transaction interest based on the number of days from the last coupon date to the actual value date of the transaction. The number of days that the system uses can be seen by reference to the Interest Days field at the beginning of the transaction.

The components of any interest calculations are all obtained from the underlying SECURITY.MASTER record. However, the user must be aware that Temenos Transact allows to over type the values in both the Interest Days and Customer Interest Amount fields with user preferred values. Transaction is affected only by any manual intervention.

For a change to the calculated amounts on a transaction affecting the organisation’s own portfolio, Temenos Transact recovers the differences during the COB batch run to ensure that the data held in respect of portfolio Profit and loss (P/L) is consistent with the details recorded in the SECURITY.MASTER along with any static data. The purpose of allowing these changes is to enable successful input of any non-standard security trades, which the user may encounter from time-to-time. Any changes made is followed through the system delivery advices. Therefore, it is important to be careful while using this facility.

Defining Customer Fees and Charges

Other fields of the SEC.TRADE such as Fees, Commission and Stamp Tax can be made to address other Temenos Transact files to obtain the relevant amounts. Refer to the online help text in respect of each field for precise details as Temenos Transact provides a flexible means to practically capture every charge that the user encounters day-to-day.

In an unlikely event, where the user cannot effect a successful default for the type of charge required, the user can use the Customer Miscellaneous Fees field to record any ad hoc fees to be added to the transaction (enter the required amount). To cover every possibility, this field supports both positive and negative input. However, at the same time the user must be aware that Temenos Transact allows overtyping a defaulted amount with either a different value or zero if the user does not require any of these amounts to be charged to the customer.

In those cases where the customer in the transaction is an internal portfolio belonging to the Temenos Transact user organisation itself, the system is aware that charges must not be made. Apart from the above named commission and fee fields, system can be parameterised to charge any number of different fees and taxes. Read Multiple Charges on Trades and Transfers for more information.

The system allows different commission to be applied based on the channel (for example, lower fee for online transactions when compared to transactions through the Relationship Manager) through which the customer placed the order. The channel is identified based on the Txn Channel field. SCTR.GROUP.CONDITION allows to setup different charges for the various products based on the channel.

After providing the details of the first customer, the user can input details for the second customer. The following screenshot displays the second customer portion of the SEC.TRADE record, when completed.

Once all customer details of the transaction are input, the user has to provide the broker details by completing the details in the Broker No and subsequent fields.

Trading from Customer to Customer and Customer to Own Book Portfolios

If the organization trades off its own portfolios directly to customers, then the user must expand the customer side so that a second set (or more if necessary) of customer fields are given. It is not necessary to provide any broker details. The same applies when a sale has been arranged from one customer to another. If two or more customer nominal fields in conjunction with their relative transaction type values net out to be zero, the user can effect successful input of the transaction to the system.

However, if the user has arranged to make a purchase or sale of the securities on behalf of the customer(s) and/or the organisations’ own portfolios through either a counterpart or counterparts, broker or brokers, the user has to complete the Broker No field and most of those following fields. The following screenshot displays the broker portion of the SEC.TRADE when completed.

Defining Broker Details

The following portion of the user guide uses the term broker, to include both broker and counterpart in the role as specified in the relative record in CUSTOMER.SECURITY.

Unlike the customer side of the transaction, the broker details other than the commissions, taxes and charges are not amended. It is not possible to carry out certain amendments as shown below in the SEC.TRADE application:

1. Amendment of total customer nominal, which would require an increase in broker side nominal
2. Change of broker on the trade
3. Change of nominal split between brokers in a multiple broker trade
4. Change of broker price

The original trade must be reversed and a new transaction to handle the amendments is required. The differences between the transactions could occur in case of an exchange rate change, as it is not possible to enter the exchange rate between the security currency and base currency in a trade. This is achieved by a contra transaction and the Contra By Ref and To Contra Ref fields in the SEC.TRADE application. With these fields, Temenos Transact supports entry of contra transactions by using the versions. Versions and version routines can be used to populate the transaction details of the original transaction on the contra transaction and other related functionality as required. These version details are not part of the release, but example versions are available through the Data Library, which can be downloaded and configured onsite. The below table illustrates ad hoc fields that are relative to the trade.

The Cum Ex Ind field is used to specify the price conditions applicable to the transaction. If the Price Qual Format field in the SM.PARAMETER application is set to SWIFT, input is validated against the Cum Indicate and Ex Indicate fields in SM.PARAMETER. If not, input is only validated against the DE.TRANSLATION application. Any values entered in the Cum Ex Ind fields in the SC.EXE.SEC.ORDERS application are carried forward, but the user can make amendments at this stage. If the Price Qual Format field in SM.PARAMETER is set to SWIFT, the values entered in the Cum Ex Ind field affect the holding balance for a corporate event. This is dependent on the parameter set up within corporate actions.

The Suppress Misc Susp field can be set to either Yes or No. This allows input only if the Hold Cash? field is set to Yes, that is, for actual settlement. This field indicates whether the miscellaneous entries like tax, P/L and so on.. are raised from SEC.TRADE and must be posted to miscellaneous suspense category defined in the Misc Cash Susp field for the actual settlement or must be raised directly. If this field is set, these entries are raised directly from the transaction instead of being raised in settlement of the transaction. This allows immediate recognition of P/L and taxes.

There are certain fields that are used in SWIFT MT540 to MT543 settlement instruction messages. These fields are explained below:

Calculating Stamp Tax on Security Trade

Stamp tax can be automatically calculated based on settings in SC.TAX.PARAMETER. It can be based on different parameters like stock exchange (for example, if stamp tax is applicable only on trades in specific exchanges, the same can be configured using SC.TAX.PARAMETER), security domicile, security type and transaction.

Posting Direct Charges to Broker

Certain charges can be paid directly to the broker instead of paying via the custodian. The broker has to be flagged in CUSTOMER.SECURITY to receive charges directly. The charges and the accounts where they need to be paid are parameterized in SC.SETT.INSTRUCT application. In such cases, the trade consideration is split into the amount due directly to the broker and amount to be paid to or received from the custodian. The instruction sent to the custodian from the trade carries only the amount to be paid or received from the custodian.

Different charges can be posted to different accounts of the broker.

Accounting entries are raised to credit the broker’s account or accounts with the direct charges. The amount due from or to the custodian is handled as usual based on whether settlement is contractual or actual.

Specifying Transfer Agency Account Details

In SC.SETT.INSTRUCT, the default beneficiary and beneficiary account details (Beneficiary Bank and Beneficiary Account) are specified. These fields in SEC.TRADE are used as payment instructions for making payment to the fund house or transfer agency.

The details can be specified for:

• Group of funds (prefixed with ‘S-‘ for sub-asset type and ‘A-‘ for asset type)
• A specific fund (SECURITY.MASTER ID) or
• All funds

The defaults can be specified by currency in which the fund is denominated.

Defining WHT on Sales

It is also possible to define a withholding tax (WHT) on security sales using SEC.TRADE. The tax to be applied is based on the conditions in the TXN.TAX.CODE record linked to the SECURITY.MASTER for this purpose.

If the TXN.TAX.CODE record US (as shown in the above screenshot) is specified in the Txn Tax Code field in SECURITY.MASTER, WHT is computed for trades involving the security based on the conditions specified here. This table allows a separate TAX or TAX.TYPE.CONDITION record to be defined for shares and bonds and the base amount must be used for computation of tax which can be the principal or both (principal + accrued interest). The following fields are also related to withholding tax.

Storing Exchange Rate for Cross Currency Accounts

There are two fields namely Cu Ex Rate Ref and Cu Ex Rate Acc , which stores the exchange rates. The former defaults the exchange rate between the system base currency and the customer’s portfolio reference currency. The latter defaults the exchange rate between the security trade currency and the customer’s financial account that is being used to settle the transaction. These rates are obtained from the CURRENCY application and are based on the latest rates entered.

If the organisation frequently has to process bulk security transactions, the user may wish to take advantage of the facility, which enables the user to enter a single bulk forex (FX) rate as obtained from the dealers based on the total FX requirement for each currency. This facility is offered as an alternative for having Temenos Transact default individual FX rates for each customer, as currently stored in the currency rates. If the user wishes to utilise the totaling of each currency, the user is not able to enter any individual exchange rates in the Cu Ex Rate Acc field as this is protected from the user input. Instead, the user has to supply any required FX rates through the Consolidate Rate fields. Read about SC.STD.SEC.TRADE application for more information of this facility.

As the trade components relative to the customer side of SEC.TRADE are supplied,the total contract value amount must be displayed in the Customer Amount Due field - a system generated no-input field. This amount always displays the actual amount to be debited or credited to the customer’s financial account.

If the user has elected to use the consolidated FX rate facility, Customer Amount Due field remains empty until the user has supplied the required FX rate in the Consolidate Rate field.

The customer fields that follow the trade component amount fields deals with how Temenos Transact handles the actual delivery. This includes the building of the SEC.DEL.CONTROL records, advices and if available on the particular system, the generation of SWIFT and other automated messaging facilities.

To round off the customer side of the SEC.TRADE, Temenos Transact displays the identification of the particular commission type that is used to compute the charge made in the Cu Commission field, if applicable. This is further complemented by adding the specific charge details displayed in the Comm Code and Comm % fields relative to FT.COMMISSION.TYPE record used and the particular charge group to which the customer is allocated so that the user can validate if he wishes to enter a different charge altogether.

Tracking of Changed Commission and Reports

SEC.TRADE holds the details of actual commission applicable if the Relationship Manager (RM) changes the default commission. The system produces the reports of commission changed or waived by the RM. Similar tracking is also available for transfer charges, safekeeping and advisory fees.

Calculating Channel Fees

While calculating the commission, the system checks SCTR.GROUP.CONDITION for any specific commission defined for the channel and calculates the commission accordingly.

The priority order based on the charges to be applied based on Security Type definition is shown below:

Setting Default Values for Depository and CU Depository

The defaulting of Depository and Cu Depository uses the following sequence:

• SEC.ACC.MASTER - Defaults a value based on the selection criteria defined the fields from Default Depository to Application Value fields.
• CUSTOMER.SECURITY - Defaults the value in Default Depository field.
• SC.CU.DEPO.DEFAULT - Enables the depository default at customer or portfolio or stock exchange level

The various options available in sequence are:

1. COMPANY*PORTFOLIO*STOCK EXCHANGE
2. COMPANY*CUSTOMER*STOCK EXCHANGE
3. COMPANY*PORTFOLIO
4. COMPANY*CUSTOMER
5. COMPANY**STOCK.EXCHANGE
6. COMPANY

• SECURITY.POSITION - Defaults the Default Depository from the existing SECURITY.POSITION (if exists), if no default value is obtained from the above applications.
• SECURITY.MASTER - Defaults the value in Default Depository field.

Applying Trade Consideration Rounding

In the SEC.TRADE and SECURITY.TRANSFER applications, it is possible to apply a special rounding and truncate the trade consideration. The Customer Gross Amount Trade and Broker Gross Amount Security fields in the SEC.TRADE and the Gross Amount Security Currency field in SECURITY.TRANSFER application reflects this truncated amount.

To enable this functionality the following set-up is done.

Calculating Broker Charges

The Charge Calc Method field in the SC.EXE.SEC.ORDERS application indicates how broker charges are calculated when the SEC.TRADE record is created. This field is available for input only if the SC.EXE.SEC.ORDERS is set to calculate charges, taxes and commissions when the SEC.TRADE is created in the HOLD status. The two methods to calculate the broker charges are:

Calculating Charges for HOLD Records

The Calc St Chgs Ihld field in SC.PARAMETER indicates whether the accrued interest, fees, charges and taxes are calculated when a SEC.TRADE transaction is created in HOLD status by SEC.OPEN.ORDER or SC.EXE.SEC.ORDERS. If the value in this field is set as Yes, the SEC.TRADE created continues to be in HOLD status, but the accrued interest, fees, charges, taxes and customer net amount (in the trade currency) are calculated. The foreign exchange rates between the customer's account currency and trade currency are defaulted at this stage. This makes the customer's net consideration available, when the SEC.TRADE is created, and makes the details available to the forex dealers, without the need to enable the transaction.

Configuring Pending Settlement Transaction

When banks act as a settlement agent, it monitors only the settlement process, and the order and execution happens externally. The position and accounting must take place only on the date when the settlement is completed to ensure that the portfolio valuations of the customers remain unaffected. The Sect Pend field in SC.PARAMETER controls this functionality. This functionality is used along with the actual settlement method to update the record in SECURITY.POSITION, only after the nominal is actually settled.

When the Sect Pend field is set to all, and when SEC.TRADE is input with transaction code given in the Sc Trans Name field in Sc Parameter, then the respective trade behaves as a pending settlement transaction.

When SEC.TRADE is authorised, the system updates the Free Nom Pend field in SECURITY.POSITION with the unsettled nominal balance. The securities are not included in Portfolio Valuations and Corporate Actions as they are not available.

Forward entry amount is not included in the cash balance which is displayed in the Forward Acc Amt field in SC.POS.ASSET. Therefore, Portfolio Valuation is not affected.

The system clears the value in the Free Nom Pend field and updates the Closing Bal No Nom field when the securities are delivered and settled using the SC.SETTLEMENT process.