Sec Trade by Temenos

8/19/2019 Sec Trade by Temenos

http://slidepdf.com/reader/full/sec-trade-by-temenos 1/17

Sec Trade

The basic SEC.TRADE transaction enables direct input to the System by the Dealers who supply

the key elements of the deal. It is by far the most important and complex as well as the most

versatile transaction in the Securities module. The SEC.TRADE records both the BUY and SELLdetails of a transaction as well as allowing more than one broker/counterpart and customer. It is

possible therefore, to perform multiple trade permutations such as illustrated in the following

table:

Table showing trade permutations possible using SEC.TRADE

The latter example is known as a BULK security trade. In other words, it comprises many

individual trades using just a single transaction, which may involve numerous screens of input.

This facility, allowing the input of multiple purchases and sales on the same transaction, 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

T24 generates the accounting entries on-line, facilities exist to be able to process large securitytransactions containing multiple transactions as a background process, thereby freeing up the

terminal for other tasks.

On the other hand, it is quite possible to have a basic transaction accepted by the System, having

passed all validation tests by entering just 10 items of information. For example, a very basic

transaction to record a purchase or sale of a security may require only the following informationentered at the deal input stage.

Customer Broker

Security Sell / BuyBuy / Sell Depot

Nominal / Amount Nominal / Amount

Price Price



It is also possible to have the trade price default to the latest price held on the security master

file, should this be required, therefore reducing by a further 2 fields to just 8 in all to achieve

input. In common with other T24 business applications and indeed most of the SecuritiesApplication transactions, the usage of a special VERSION enables the setting up of user defined

input screens. If it is known that a field will receive a default, then this field may be omitted from

the display. Equally, other VERSION records may be defined for transactions using brokers andcustomers with whom the user entity deals frequently. In the latter instance, these defaults would be supplied by the VERSION itself.

To ensure that T24 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 is kept as

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 arecredited 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 T24

modules).

The following extracts will attempt to illustrate the versatility of the T24 SEC.TRADE

application, while at the same time, provide you with instructions as to how to get the best outthis powerful transaction. They have been broken down into several screens to enable it to fit

onto the pages of this guide.

The structure of the Sec Trade ID consists of the following:

SCTRSC – Used to identify the transaction as a SEC.TRADE .

yy – the year that the transaction is being enter, i.e. 04 would be the year 2004

ddd – the Julian day that the transaction is being entered, i.e. the number of days since the

beginning of the year, so 2nd January would be 002.

nnnnn – the transaction sequence number

A common array of lead prefix (0-9,A-Z) excluding vowels will be built up. These lead prefix

values are based on the session number depending upon the session number the sequencing

would be as below where the bold letters indicate the lead prefix.

Example:

1.

SCTRSC00335B0003



SEC.TRADE example

The first extract shows the initial details necessary to the recording of the security being

transacted. In this particular extract, the no-input fields are shown in light grey. These contain

either noteworthy information that may complement a choice you made in an earlier field orshow defaulted or no-change system calculated amounts etc.

For example, the SECURITY.CURRENCY and PRICE.TYPE fields in the above extract areobtained from the SECURITY.MASTER file appertaining to the security that you enter in the

SECURITY.CODE field. These assist you during your completion of the remainder of the

transaction and are also an aid to ensuring that you have selected the correct security. The

particular example above 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 would have indicated the current interest rate and the

number days elapsed since the last coupon date and the value date of the trade respectively. Forshare type transactions, interest is non-applicable.

Most information can be made to default although you can always overtype an alternative

permissible value. By way of example, the depository is defaulted from the underlying

SECURITY.MASTER file record provided it has been recorded within the

DEFAULT.DEPOSITORY field in that file. This field allows input and you may select adifferent depository if found necessary. This particular field advises T24 as to where your

organisation requires the securities delivered to or from. Please note that you cannot combine

different depositories on the same transaction in respect of securities being delivered into or

withdrawn from control by your organisation.



Further defaulting can take place in the TRADE.DATE and VALUE.DATE fields. The former

always defaults to the System date but will allow earlier business days (and non-business subject

to override) for late entry trades when required. The latter can also default and this depends uponthe information, which is recorded in the particular STOCK.EXCHANGE record appertaining to

the stock exchange at which the security is being traded. However, care should be taken if and

when you use this facility.

SEC.TRADE example



Having advised T24 as to the security being transacted, the trade and value dates and your

depository, you now need to describe the customers’ details. As this is a bulk security trade, it

will contain more than a single customer.

Only those customers who have been set-up in the CUSTOMER.SECURITY file (as Customers)

may be entered in the CUSTOMER field. This done, you must now tell T24 whether thecustomer is buying or selling the security. This is done by entering the particular

SC.TRANS.NAME applicable to buy or sell into the CUST.TRANS.CODE field. Remember that

if you are unsure as to the value, you may drill down to the SC.TRANS.NAME file to obtain therequired transaction code.

Once you have entered the transaction code, you now have to advise the identification of thecustomer’s portfolio account. T24 will always default to the first portfolio belonging to the

CUSTOMER. For example, a CUSTOMER (1250) owning portfolios 1250-1 and 1250-75 will

always have his securities defaulted to portfolio 1250-1. If you require the securities held in or

withdrawn from the other portfolio, you will always have to enter it manually.

The next field, CUST.ACC.NO, requires the identification of the customer’s financial

ACCOUNT to be used to either obtain or pay the funds required. This field can be the subject ofa very elaborate defaulting process. To obtain precise details as to how this process works, you

should refer to the Portfolio Management User Guide. In all probability, these defaults will

already have been set-up - just hit the <CR> key to see. You can, if you wish, enter an alternativeACCOUNT that does not have to belong to that CUSTOMER.

Note that a customer is allowed, for example, to pay for securities using any currency they wishso you may enter any financial ACCOUNT. Provided it has been pre-defined on the

SEC.ACC.MASTER, T24 will use the current Forex rates to arrive at the amount of currency

required but you are able to type in your own specified conversion rate if required.

In the case there being a need to defining specific accounts to pay or receive funds as appropriate

for specific actions, please refer to the field-by-field help covering the field AC.DEF.SYS.CODEand those fields immediately following. The definition of an account NOT belonging to the

portfolio customer will cause an override during the opening or changing of a portfolio record.

In addition, when a particular transaction has been designated to use another customer's account,

any occurrence of that transaction will also give rise to an override situation.

The next step is to advise how many share-type or how much nominal bond-type security the

customer is buying or selling. Once you enter this amount in the CUST.NO.NOM field, it is

immediately validated to ensure that it complies with the trading units recorded on the

underlying SECURITY.MASTER file TRADING.UNITS field. You must therefore ensure thatthis amount is divisible by the trading unit. Further, you must also make sure that it is equal to or

greater than the trading unit. In the case of unit trust and fund type securities, which can be

traded in fractions, the underlying SECURITY.MASTER file TRADING.UNITS field should beset to “0” to enable you to process these particular types.



When the number of security units has been entered, you must input the buy or sell price in the

CUST.PRICE field. Of course, you should enter the price at which the trade has been transacted

but there may be instances, especially when entering a large number of customer transactions (asin a bulk SEC.TRADE ) when you may utilise a price defaulting procedure. For details of this

timesaving facility, please refer to the section describing the SC.STD.SEC.TRADE file.

As you progress through the transaction and, provided you are using the <CR> key, T24

automatically calculates various information. For example, having entered the price relative to

the trade, the next three fields, CUST.TOT.NOM,CU.GROSS.AM.SEC andCU.GROSS.AM.TRD, are all populated depending upon the amount of the security traded and

the price. As both the nominal and price fields are multi-value, in that you may enter tranches of

purchases or sales for the same customer/portfolio, these fields will indicate the total numbers of

the security, the value of the transaction (before addition of other items such as tax, charges andinterest) in both security and trade (settlement) currency.

These fields are system calculated therefore you would not be able to access them. So, having

entered the required amount of the security and the price at which it has been transacted, youshould now be located in the CU.REALLOWANCE field. This field, as its name implies,

enables you to enter a concessionary re-allowance rate if it is being granted to the customer.

Since this is a rate field, an entry only makes sense for bond type instruments where the re-

allowance is calculated as a percentage of the nominal amount. Therefore, should you wish togrant a re-allowance in respect of a share-based transaction; you may enter the re-allowance

amount directly into the CU.REALLOW.AMT field immediately following.

Note that this is a “special” field in that you are allowed to enter the rate together with a leading

“-” (minus) sign. Note however, that omitting the minus sign indicates that you are granting an

allowance, therefore reducing the amount, which the customer has to pay for his securities. Ifyou do enter the minus sign, then T24 will add the calculated re-allowance to the amount that thecustomer has to pay.

The entry of a rate in the CU.REALLOWANCE field will cause the System to calculate the re-

allowance amount automatically. This will be shown in the CU.REALLOW.AMT field. If you

do not require a re-allowance amount, there is no defaulting so you should continue to theCUST.INTR.AMT field.

This field will only ever show a value if the underlying security is an interest-bearing instrument.In this case, hitting <CR> over that field will cause T24 to default the transaction interest based

on the number days from the last coupon date to the actual value date of the transaction. The

number of days, which 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, you should be aware that T24 allows you to overtype thevalues in both the NUMBER.DAYS and CUST.INTR.AMT with values of your own. If you

need to do this for any reason, it is important that you understand that only the transaction is



affected by any manual intervention. For a change to the calculated amounts on a transaction

affecting your organisation’s own portfolio, T24 will recover the differences during the Close of

Business batch run so as to ensure that the data held in respect of portfolio P/L is consistent withthe details recorded on the SECURITY.MASTER and any static data. The sole purpose of

allowing these changes is to enable the successful input of any non-standard security trades,

which you may encounter from time-to-time. Any changes you make will follow through to theSystem delivery advices. You should therefore take particular care if you ever make use of thisfacility. It is mentioned here only because the two fields are not protected against manual

change.

Other fields in this portion of the SEC.TRADE such as fees, commission and stamp tax can all be

made to address other T24 files to obtain the relevant amounts. Please refer to the on-line

HELPTEXT in respect of each field for precise details as T24 provides you with a very flexiblemeans of capturing practically every charge that you can encounter from day-to-day. In the

unlikely event that you cannot effect a successful default for the type of charge you need, you

can use the CU.MISC.FEES field to record any ad hoc fees to be added to the transaction -

simply type in the amount you require. To cover every possibility, this field supports both positive and negative input. At the same time however, you should be aware that T24 will allow

you to overtype a defaulted amount with either a different value entirely or to enter “0” if you donot require any of these amounts to be charged to the customer. Note that in those cases wherethe customer in the transaction is an internal portfolio belonging to the T24 user organisation

itself, the System is aware that charges should not be made.

It is also possible to define WHT on security sales using SEC.TRADE application. The tax to be

applied is based on the conditions in TXN.TAX.CODE record linked to the SECURITY.MASTER

for this purpose.



TXN.TAX.CODE

If the TXN TAX CODE record US, as given above, is specified in the SECURITY MASTER fieldTXN TAX CODE, WHT would be computed for trades involving the security based on the

conditions specified here. This table allows a separate TAX or TAX.TYPE.CONDITION to be

defined for shares and bonds and the base amount to be used for computation of TAX could bethe principal or both (Principal + accrued interest).

Fields, CU.WHT.PERC, CU.WHT.TAX and WHT.TAX.CODE, are also related to thewithholding tax. The CU.WHT.PERC signifies the tax rate applicable as defaulted from the Tax

rate in the file TAX . The CU.WHT.TAX field would indicate the amount after computing the tax

value based on the Tax rate in the field CU.WHT.PERC and the amount. The net amount tradewould be computed after deducting the WHT, if any.

There are two fields, - CU.EX.RATE.REF and CU.EX.RATE.ACC which both store exchangerates. The former will default the exchange rate between the System base currency and the

customer’s portfolio reference currency. The latter defaults the exchange rate between thesecurity trade currency and the customer’s financial ACCOUNT that is being used to settle the

transaction. These rates are obtained from the CURRENCY table and are based on the latest ratesentered.

Note that if your organisation frequently has to process bulk security transactions, you may wishto take advantage of the facility which enables you to enter a single bulk FX rate as obtained

from the dealers based on the total FX requirement for each currency. This facility is offered as

an alternative to having T24 default individual FX rates for each customer as currently stored inthe currency rates. If you do wish to utilise the totalling of each currency, then you will not be

able to enter any individual exchange rates in the CU.EX.RATE.ACC field, as this will be

protected from user input. Instead, you will have to supply any required FX rates via theCONSOL.RATE fields. For further details of this facility, please refer to that part of your UserGuide, which describes the SC.STD.SEC.TRADE file, and later in this document in the

explanation of the CONSOL.RATE field.

Having supplied the trade components relative to the customer side of the SEC.TRADE , the total

contract value amount should be displayed in the CU.AMOUNT.DUE field - a System generatedno-input field. This amount always shows the actual amount to be debited or credited to the

customer’s financial account. Note that if you have elected to use the consolidated FX rate

facility (described above), then this field will remain empty until such time as you have supplied

the required FX rate in the CONSOL.RATE field.

The customer fields that follow the trade component amount fields all deal with how T24

handles the actual delivery. This includes the building of the SEC.DEL.CONTROL records,advices, and if available on your particular System, the generation of SWIFT and other

automated messaging facilities. Please refer to the HELPTEXT for each field and the User Guide

detailing the T24 Delivery Application.



To round off the customer side of the SEC.TRADE , T24 displays the identification of the

particular commission type, which was used to compute the charge made in the

CU.COMMISSION field if applicable. This is further complemented by the addition of thespecific charge details shown in the COMM.CODE and COMM.PERCENT fields relative to

FT.COMMISSION.TYPE record used and the particular charge group to which the customer has

been allocated so that you can check whether you wish to enter a different charge altogether.

Having entered the details appertaining to the first customer, you may now expand the

transaction to enable you to input the details for the second customer. Please refer to the UserGuide chapter dealing with T24 navigation, which will explain the methods by which you can

utilise the multi-value fields.

The following extract shows how a typical second customer portion of the SEC.TRADE may

look when completed.

SEC.TRADE example

Having successfully completed all customer details of the transaction, you now need to providethe broker details by completing the details in the BROKER.NO and subsequent fields. However

before continuing, please note that if your organisation trades off its own portfolios directly to

customers then you should expand the customer side so that you are given a second set (or moreif necessary) of customer fields. Should this be the case, it will not then be necessary to provide



any broker details. The same applies when you have arranged a sale from one customer to

another. Provided that the two or more CUST.NO.NOM fields, in conjunction with their relative

CUST.TRANS.CODE values net out to zero, then you will be able to effect successful input ofthe transaction to the system.

However, if you have arranged the purchase or sale of the securities on behalf of yourcustomer(s) and/or your Organisation’s own portfolios through either a counterpart, counterparts,

broker or brokers, then you will need to complete the BROKER.NO field and most of those

following.

The next screen extract attempts to illustrate how the broker portion of the SEC.TRADE might

look when completed.

Inputting broker portion of SEC.TRADE

The following portion of your user guide will use the term “broker” to include both broker and

counterpart - the role as specified on the relative CUSTOMER.SECURITY record. The

BROKER.NO field identifies the broker with whom your Organisation is arranging the security purchase or sale. You may enter the basic customer mnemonic appertaining to the broker, if you



know it. T24 will then perform an immediate check to satisfy itself that your chosen id is in fact

a broker or a counterpart. If not, your entered value will be rejected by this validation process.

The next field, BROKER.TYPE, confirms the role of the broker entered in the BROKER.NO

field and is defaulted from the relevant CUSTOMER.SECURITY file. This defaulting only occurs

when the underlying broker has been set-up to perform a single role. In those cases where the broker may act in more than a single capacity, you will need to let T24 know the precise role.

Note that to speed up input, you can type “B” to indicate broker or “C” to indicate that the

required role is counterpart.

Once you have successfully defined the role of the broker, you will now have to advise T24 as to

whether the broker is buying or selling the security. As with the customer side of theSEC.TRADE , you should enter into the BR.TRANS.CODE field the required purchase or sale

transaction from the SC.TRANS.NAME file.

It is now a question of advising T24 as to the delivery details with regard to both the cash and

security components of the transaction. The first field, BR.ACC.NO, unlike the name implies, isto specify your organisation’s Nostro over which the financial entries are to be posted. Payment

can, if required, be effected over a Vostro ACCOUNT also. To affect a default, you will have toensure that there is a record existing for the settlement currency on the NOSTRO.ACCOUNT file

specified for use by the SC application. If this is not the case, then you may enter any valid

Nostro or Vostro ACCOUNT on the System, provided of course that the currency agrees to thesettlement currency.

Provided that you have correctly specified a valid ACCOUNT over which to pass the requiredentries, you may now have to specify the depository that the broker is using in the

BROKER.DEPO field. Whether this is a mandatory field or not depends upon the settlement

method being used. For example, if you wish to effect the settlement via Euroclear, then to beable to build a valid formatted message type, T24 will require this information and will remindyou with a message if this field is blank. If it is not required, you may leave the field blank

although T24 will not object if you wish to specify the broker depository for the sake of good

information.

If you have to enter information in this field because for example you are using Euroclear, thenyou should enter a valid depository. Note that you can enter any valid CUSTOMER. Unlike the

DEPOSITORY field at the beginning of the SEC.TRADE , which tells T24 where your

organisation is to receive or deliver, which requires a response of a valid depository as defined in

the CUSTOMER.SECURITY file, you can enter any valid CUSTOMER record specifying thedepository, which the broker is using. If the broker depository does not exist on the CUSTOMERfile, you can put the SEC.TRADE on “hold” and create a CUSTOMER record. However, if the

depository is used very little, you may not wish to open a CUSTOMER record so, in these

instances, T24 will allow you to type the depository name and address details using free formatcharacters as necessary. There are a number of multi-value fields available to enable you to

perform this “last resort” function if you require it.



Having satisfactorily specified the broker depository, you may now enter the broker account

number by which it is identified at that same depository. This is performed in the

BR.SEC.DEPOT.AC field and may default provided your broker is using either Euroclear,Cedel, BNB or SEGA settlement systems and his account number has been defined on his

relative CUSTOMER.SECURITY record. If you are not using one or other of these particular

depositories, then you may type in any value to identify the broker’s account at the depotspecified.

You will now be located in the BR.NO.NOM field where you should now enter the amount ofthe security being bought from or sold to the broker. Suffice to say, this amount should comprise

the total of the customer side of the transaction. This will apply unless you have arranged to

accommodate the customer requirements using more than a single broker. If this is the case, then

you will need to expand the fields and enter the second broker details in the same way as the first broker. On input, T24 will check that the totals of both sides of the transaction do in fact net out.

Having satisfactorily entered the required amount of security relating to the broker, you should

now enter the price arranged with him into the BR.PRICE field. If you need to, you can expand both the BR.NO.NOM and BR.PRICE fields if you have arranged the transaction in several

tranches using different prices.

This done, T24 will now update the BR.TOT.NOM, BR.GROSS.AM.SEC and

BR.GROSS.AM.TRD fields. These show the total amount of the security arranged with the broker, the gross value of the security in security currency and the gross amount in the trade

currency whether or not the transaction is for settlement in a different currency or not. The

values in these fields will be calculated based on the sum of the BR.NO.NOM multi-value fieldsfor each broker.

You should now be located in the BR.REALLOWANCE field. This field and theBR.REALLOW.AMT field immediately following, work in exactly the same way as theidentical two fields on the customer side of the transaction. It is important to understand how

these two fields work. If you are purchasing securities through the broker on behalf of a

customer then the entry of an amount will reduce the overall amount you have to pay the broker.So if you ever need to add a re-allowance for a purchase then use the leading “-” sign. If you

have arranged a sale to the broker, then entry of an amount will cause that amount to be added to

the overall proceeds. Therefore in this case, you would again have to add a leading “-” if youwished to reduce the overall precedes which your organisation is to receive.

Until you are used to this process, you should compare the contents of the BR.GROSS.ACCRfield to the contents contained in the BR.GROSS.AM.TRD field. The former contains the

consideration plus any interest if applicable and the latter field contains the total contract value,

which would include any re-allowance. You should be able to ascertain the effect of your chosen

input into the re-allowance field.

If the underlying security is an interest-bearing instrument, then next field, BR.INTR.AM.TRD,should contain the T24 calculated interest amount relative to the nominal amount dealt with the

broker. Please refer to the section describing the contents of the CUST.INTR.AMT for fuller



details as to usage of this field. Note that if you hit the <CR> key over this field, T24

immediately adds the interest, if applicable, but more importantly, the cursor is located over the

BR.FEES.MISC field further down the transaction.

This little process is vitally important because it enables T24 to default the commission, foreign

fees, stamp tax and, if applicable, EBV fees fields leaving you to supply any ad hoc fees. You arefree to move back to any field and either type in a different amount altogether or simply hit the

<CR> key over the field to remove the contents.

You should now be located in the BR.BROKER.COMM field. The previous field

BR.GROSS.ACCR is a no-input system generated field, which illustrates the basic amount of the

transaction, plus any interest if applicable. You should refer to this field to ascertain the trade proceeds prior to the addition or subtraction of any commissions, taxes, charges and other ad hoc

amounts, which would affect the overall transaction proceeds. The current field,

BR.BROKER.COMM, will contain any commission relative to the trade. This is based on the

rules contained within the relative STOCK.EXCHANGE file as defined in the

STOCK.EXCHANGE field near the beginning of the transaction, which in turn should provide alink to one of the stock exchange calculation countries. For example, if the transaction is settling

via the Luxembourg exchange then there will be a file called STK.EXC.LU, which shouldcontain the various commission rates to apply. Note that you can overtype this amount with an

entirely different amount, including “0” if necessary.

The next field, BR.FOREIGN.FEE, works in a similar way to the previously described

BR.BROKER.COMM field; in that you may overtype any fee defaulted by the System as set-up

on the underlying STOCK.EXCHANGE file.

If you wish to enter a charge or commission amount in the event of your entering a transaction

on behalf of a client only, then the next field, CL.COMMISSION, enables you to enter theamount you require. Input is only allowed when the transaction includes a client and is inhibitedwhen you are completing the current multi-value fields in respect of a broker or counterpart.

As with the BR.BROKER.COMM and BR.FOREIGN.FEE fields, the next field,

BR.STAMP.TAX contents will also depend upon whatever has been set-up in the underlying

STOCK.EXCHANGE file. Here too, you may overtype whatever value has been defaulted if youneed to change it in any way.

The next field, BR.EBV.FEES, will detail if applicable, special any fees that may apply. Notethat this is a special field intended for those T24 users in Switzerland. However, the contents

depend upon the rules as laid down in the STK.EXCH.LOCAL file relative to your Organisation.

As with the customer side of the transaction, a further field BR.FEES.MISC, has been added toaccommodate those instances when you may encounter any miscellaneous add hoc fees that

cannot be readily set-up in the various STOCK.EXCHANGE files.

Should you have defined in SC.STD.SEC.TRADE for demarcating and allocation of the Treasury

Profit to the originating branch, the user shall be required to input the Treasury Price also in the



SEC.TRADE , which is again optional, in the absence of which the system will post the difference

between the BR.PRICE and CUST.PRICE to the MARKET.PL.CAT stated therein in

SC.STD.SEC.TRADE .

Once Input, the difference between the treasury price and broker price shall get posted to the

respective Market Profit and Loss category defined therein in SC.STD.SEC.TRADE .

Any difference between the Treasury Price and Customer Price would be posted to the respective

Treasury Profit and Loss category as defined in SC.STD.SEC.TRADE.

SEC.TRADE with a Treasury Price

T24 will now advise you to the net contract value for the broker in the trade currency, in the

BR.NET.AM.TRD field. This amount is made up of all components (commissions, taxes etc.) in

respect of the broker and represents the amount to be paid or received from that broker.

This is used to calculate the contents of the settlement amount in the field, BR.ACCOUNT.CCY.

The previous field, BR.ACCOUNT.CCY, simply confirms the currency of the brokers cashaccount over which they have requested settlement defined by you or by default in the earlier

BR.ACC.NO field. Note that unlike the customer, who is able to pay for their securities usingany currency they wish, T24 will not allow the broker to be paid in any currency other than thesecurity currency.

The next field, BR.DELIV.INSTR, is similar to the earlier described customer field,CU.DELIV.INSTR except, you specify the broker requirement. The value here should comprise

a valid SC.DEL.INSTR file component but defaulting can occur or you may enter a valid choice

of your own. You should note that you would not be able to affect a delivery against payment

instruction if you and broker depot differ. The values entered here also affect the T24SEC.DEL.CONTROL application which will only expect security movements if the transaction is

free of payment but both cash and securities are dealt on an against payment basis. The various

validation rules are obtained using the “rules” specified in each SC.DEL.INSTR record.

In addition to the above, these instructions will form part of the message formats when building

SWIFT type messages for use when settling via Euroclear, Cedel and other automated settlementfacilities.

Should the user, however, wish to suppress instructions/advice to customers, brokers,depositories or any combinations thereof, they can do so by correctly populating the YES/NO



fields below. The ADVICE.DEFAULT field in SC.PARAMETER controls the default for these

fields.

Figure 23 – Selecting advices/payments in SEC.TRADE

You will by now be located in the BR.BEN.BANK.1 field in which T24 should have defaulted

the broker’s bank. This only applies where the broker does not maintain account facilities at your

Organisation. In the event of there being no default, this would have been obtained from the AGENCY file, you will be invited to enter a valid customer to identify the beneficiary bank. If

this has not been set-up on the customer database, you then have a choice of putting the

transaction on “hold” and creating the required record and related AGENCY details or you may

prefer to type the bank name and address instead.

There may be occasions when you need to utilise a second beneficiary bank in order to properly

effect the required payment to the broker. If this should be the case, then you need to proceed to

the BR.BEN.BANK.2 field and enter a valid CUSTOMER id to identify the second bank.

If you are preparing a settlement to a lesser used bank and do not wish to set-up customer and

agency records, then you can free-type the details into the BR.BEN.ADDR set of multi-valuefields. Here you should enter both name and full address in respect of that bank. Please note that

these fields are very complex as are in-built controls designed to protect you from erroneous

input. This being the case, you should refer to the HELPTEXT included with these payment

fields for a full description, which includes details such as how to affect a four-party transfer.

It is worth remembering that these fields are there only for convenience. Wherever possible, you

are advised to ensure that your database includes all the banks you are likely to encounter,together with the relevant AGENCY details, thereby ensuring that T24 can help you eliminate the

need to enter repetitive settlement details time and time again.

Unlike the customer side of the transaction, the broker details other than the commissions, taxesand charges could not be amended. It would not be possible to carry out certain amendments as

shown below in 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.

Under the current functionality, the original trade needs to be reversed out and a new transaction

input to handle the above amendments. However, differences between the transactions couldoccur in case of an exchange rate change, as it is not possible to input the exchange rate between

the security currency and base currency in a trade.

However, this could be achieved by a contra transaction by using two fields on the SEC.TRADE

called CONTRA.BY.REF and TO.CONTRA.REF. The TO.CONTRA.REF specifies whether thetrade being entered is a contra to an existing transaction and if so the transaction reference of the

original trade. The CONTRA.BY.REF would specify the transaction reference of the contra

trade on the original transaction. In a contra transaction, the EXCH.RATE.SEC would be an

input field and the user could amend the default rate to a rate applicable to the originaltransaction.

With the addition of the above fields, T24 is able to support entry of contra transactions throughthe use of 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 will be available via the

“Data Library” which could be downloaded and configured on-site. It should be noted that these

example VERSION records will be generic and a certain amount of local development may berequired to make them more suitable to the business environment in which they are being used.

The final screen extract illustrates ad hoc fields, which are relative to the trade.



Ad-hoc fields at end of SEC.TRADE input

The CUM.EX.IND field is used to specify the price conditions applicable to the transaction, ifthe PRICE.QUAL.FORMAT field on SM.PARAMETER is set to “SWIFT”, input is then

validated against the CUM.INDICATE and EX.INDICATE fields on SM.PARAMETER, if not

then input is only validated against the DE.TRANSLATION table. Any input made to theCUM.EX.IND fields on SC.EXE.SEC.ORDERS are carried forward, but amendments are

allowed at this stage.

If the PRICE.QUAL.FORMAT field on SM.PARAMETER is set to “SWIFT”, then the values

entered in the CUM.EX.IND field will affect the holding balance for a corporate event. This is

dependent on the parameterisation within corporate actions, further information can be foundwithin the Corporate Actions section of this user guide.

(c) Temenos Systems 2013

Sec Trade by Temenos

Documents

Transcript of Sec Trade by Temenos