SECURITIES - CAPITAL GAINS TAX

Application Overview

Capital Gains calculations in securities processing could be based on the average price of acquiring securities. A disadvantage with this method is that it does not allow for the correct inflation adjustment to be made to the original cost of the security. This gave rise to a requirement to provide a FIFO (First In First Out), LIFO (Last In First Out) or AVERAGE (Average price) method that allowed for being able to adjust the cost of a security acquired with the inflation index applicable at the time of its disposal. An additional requirement was to apply taper relief percentages to a gain prior to calculating any tax due. T24 securities module maintains a Capital Gains Transaction Base.

SECURITIES - CAPITAL GAINS TAX

Setting up the System

This CGT Transaction base can be initially built up from the raw security transactions, SECURITY.TRANS records, input into the system over the period of time. Only security transactions generated by SEC.TRADE, SECURITY.TRANSFER or DIARY/ENTITLEMENT will update the transactions base. The methods used in building the base must be specified in the CG.PARAMETER parameter file. The parameters allow for flexibility in defining time frames and processing orders in the trading periods. For example this could be defined as shown under:

Time Period Method Used Prior to 6th Apr 1965 LIFO (Last in First Out) 7th April 1965 to 6th April 1982 '82 Pool (Trades are amalgamated into

one with the cost decided with the price of the security at 6th April 1965)

7th April 1982 to 6th April 1985 '85 Pool (Trades are amalgamated into one with the cost decided with the price of the security as at 6th April 1982)

After 7th April 1985 FIFO The CGT position base is maintained in a trade date - time order. The transaction date and time, costs, expenses and accrued interest are taken directly from the SECURITY.TRANS records that lead to the update. Exceptions to this rule are only applicable when RULES processing is used, see CG.TXN.RULES for definitions of this functionality. The cost is extracted from GROSS.AMT.SEC.CURR, accrued interest from INTEREST.AMT, and expenses from the sum of COMMISSION, BROKER.COMMS, STOCK.EXCHANGE.FEES, OTHER.FOREIGN.FEES, STAMP.TAX, EBV.FEES and FEES.MISC.

Figure 1 - Example SECURITY.TRANS - CGT data

In the simplest form the above details would give rise to two transactions being added to the base. The cost of GBP1502.00 and expenses of GBP7.51 would be split proportionally (1/3 and 2/3, the nominal ratios). The trade date of 23rd December 1999 and time of 14:12 would be used to add the transactions into the correct position in the base.

Figure 2 - Example CG.TXN.BASE

Figure 3 - Example CG.TXN.BASE

SECURITIES - CAPITAL GAINS TAX

Application Design

Initial Set-up Procedures

There are several actions that need to be taken in order to be able to use the CGT processing. This has been illustrated step-wise as under.

SEC.ACC.MASTER

It should be noted that although the system allows transactions to use accounts not added to SEC.ACC.MASTER field ACCOUNT.NOS the capture of STMT.ENTRY ids to CG.TXN.BASE relies on the link being present. This link is essential so that an account number can be linked to a portfolio, and hence the CG.TXN.BASE. Even account numbers belonging to SEC.ACC.MASTER records in the same PORTFOLIO.GROUPING will cause the same problems in the CG.TXN.BASE. If this should happen the tax entries will be posted but the tax STMT.ENTRY ids will not be added to the CG.TXN.BASE nor will the TAX.STATUS field be changed to POSTED. Furthermore reversal of these underlying transactions which generated the tax entries will not reverse the tax entries at all as the TAX.STATUS field would have been showing TO_BE_CALC misleading the system that no tax entries exist. Therefore manual adjustment by DATA.CAPTURE will be required to rectify the situation.

SC.PARAMETER

To allow the system to maintain the data for calculation of capital gains in CG.TXN.BASE, set the field CG.BASE.UPDATE to "YES" or “RULES”.

Figure 4 - Example SC.PARAMETER Record

CG.PARAM.CONDITION

The application has been further enhanced to allow the definition of classes or groups in a file called CG.PARAM.CONDITION and to apply different tax rules to these groups using applications called CG.PARAMETER. Each CG.PARAM.CONDITION will define the group based on characteristics of the customer from the customer file and the securities to be traded from the SECURITY.MASTER and SUB.ASSET.TYPE files. It should be noted that when checking what CG.PARAM.CONDITION applies to a transaction the records would be checked in alphabetical order and the condition applied from the first set of parameters that match. Therefore the T24 User must ensure that conditions are set up to correctly match data with the most specific conditions to be checked first and more general conditions last. T24 will select the first match it finds not the best match. For instance a if two CG.PARAM.CONDITION records exist where one has the CUSTOMER RESIDENCE field as EQ GB and the other has the CUSTOMER RESIDENCE.REGION field set to LONDON the more accurate match for a CUSTOMER with a RESIDENCE.REGION EQ LONDON would be the second record. However the first record is also true so a selection will be made of the record, which is discovered first in the list. Capital Gains Tax (CGT) is chargeable on capital gains generated by disposal of securities that have been acquired at a fixed cost. The responsibility for withholding CGT (collecting and paying to the relevant Tax Authority) can be with the financial institution (the T24 user) acting on behalf of the Customer who has the tax liability or with the Depository settling the disposal transaction. Where the T24 user is responsible for withholding the tax it is termed as LOCAL and where the Depository withholds the tax it is termed SOURCE. It will be possible to define on each CG.PARAM.CONDITION record whether CG Tax is to be LOCAL or SOURCE. As tax laws change different groups of Customers or Securities will come into or drop out of the SOURCE net therefore it must be possible to allow a change from SOURCE to LOCAL or visa versa from a specified future start date. This is achieved by input values of LOCAL or SOURCE to the SRC.LCL.TAX field. The associated TAX.START.DATE field will be left blank for the earliest LOCAL or SOURCE setting. A change can be effected by the input of a future date into the TAX.START.DATE field and the SOURCE or LOCAL value into the following SRC.LCL.TAX field. Where local is selected the resultant STMT.ENTRY records will debit the customer and credit the tax category account. Where source is selected the customer will be debited and the Depository nostro account will be credited, as the Depository will usually deduct the Source Tax from the disposal proceeds.

Figure 5 - Example CG.PARAM.CONDITION

The above screenshot will be applied to all customers who have a value of GB in the field RESIDENCE in the CUSTOMER application. Groups may be defined using the applications CUSTOMER (as above), SEC.ACC.MASTER, SECURITY.MASTER or SUB.ASSET.TYPE and any of the fields in these applications. Any number of conditions may be applied. If the transaction is before 06 April 1997 then the T24 institution will withhold the tax, after that the Depository will withhold the tax.

CG.PARAMETER

Once the above group has been set up the CG.PARAMETER application is used to set the tax, Capital gain method and related parameters.

Figure 6 - Example CG.PARAMETER

The above settings indicate that the capital gain method to be used when calculating a gain will be FIFO (first in, first out). Any purchases made within 7 days (REACQ.PRD) of a sale will drop any associated losses on these sales. The setting for REACQ.PRD and REACQ.DROP.LOSS can also be specified at SECURITY.MASTER level. The settings from SECURITY.MASTER will take precedence over those at CG.PARAMETER level. The tax charged on any gain will be defined using the TAX.TYPE.CONDITION CGT. For details on how to set up taxes and use of the TAX.TYPE.CONDITION application please refer to the System Tables section of the User Guide. When the gain is calculated the inclusion or exclusion of accrued interest and expenses in the costs is determined by the field settings in CG.INCL.ACCR.INT, CG.INCL.EXPENSE, WCG.INCL.ACCR.INT and WGC.INCL.EXPENSE. The setting of the parameters for inclusion/exclusion of accrued interest and expenses can be specified additional at ASSET.TYPE level or SECURITY.MASTER level. The same fields exist in these applications and the system will use the settings from SECURITY.MASTER in preference to those in ASSET.TYPE, which in turn will be used in preference to those in CG.PARAMETER. Before any tax is calculated on a gain the inflation index will be applied (USE.INFL.INDX = YES), and taper relief will be applied (CG.TAPER.RELIEF = 2) using the record defined in CG.TAPER.RELIEF. If USE.INFL.INDX is not YES then no indexation will be applied and if the field CG.TAPER.RELIEF is blank then no taper relief will be applied. Taper relief may not be applied if any of the CG.METHOD multi-values are AVERAGE. Where a disposal of securities acts against multiple acquisitions the disposal proceeds are applied proportionately against each acquired nominal to calculate a gain or loss. These gains and losses are netted and tax will only be applied if the net effect is an overall gain.

For example using the FIFO method purchases of: 1000 for USD 10,000.00 1000 for USD 20,000.00 1000 for USD 40,000.00 and a sale of 3000 for USD 180,000.00 gives separate CG amounts of USD 50,000.00 gain USD 40,000.00 gain USD 20,000.00 gain So tax would be charged on the net gain of USD 110,000.00 But a sale of 3000 at USD 90,000.00 gives separate CG amounts of USD 20,000.00 gain USD 10,000.00 gain USD 10,000.00 loss So tax would be charged on the net gain of USD 10,000.00. Tax is obviously not charged where there is a net loss.

SECURITIES - CAPITAL GAINS TAX

Overview of Input and Processing

Rules on reacquisition of securities

Reacquisition of a security is defined as the disposal of a certain security followed within a defined time period by one or more acquisitions of the security. Any capital loss arising in such cases is not used in the capital gains calculations. This will only be applicable where the capital gain for a customer is calculated over a period of time and gains and losses netted to produce a gain for the period. Where tax is deducted at transaction level no tax is calculated on losses and losses are not carried forward to subsequent transactions. This has been illustrated with examples as under:

The above sale results in the following updates:

The above sale has resulted in a loss of 2,000 to be recorded. If subsequent to this sale the security were reacquired within the two months then we would get the following updates:

This means that if there were a subsequent sale of the security the loss shown in the table above would not be taken into account for the chargeable gain calculation. This is illustrated as under:

The above sale would give the following new updates:

FIFO PandL = Apportioned Costs Disposed of - Trade Value of the Sale. The profit that will be taxed the capital gains will therefore be 7,000. If instead the reacquisition were made after two months of the sale a different scenario would emerge as shown under:

This means that if there were a subsequent sale of the security the loss shown in the table above would be taken into account for the chargeable gains calculation. This is illustrated as under:

The above sale would give the following new updates:

FIFO PandL = Apportioned Costs Disposed of - Trade Value of the Sale In this case the profit that will be taxed the capital gains will therefore be 5,000 for the period.

Inflation Index

Inflation indexation can be applied to the costs of the original acquisition; the field USE.INFL.INDX in CG.PARAMETER will determine whether it is applied. The inflation index to be used is determined by the CUSTOMER fields RESIDENCE and RESIDENCE.REGION. The RESIDENCE.REGION will take priority over the RESIDENCE field. If RESIDENCE.REGION is set then the inflation index figures will be retrieved from the REGION application, otherwise they will be retrieved from the COUNTRY application. Two type of inflation index values are supported by T24. These are Standard ‘STD’ where as the months/years progress the index for the current month increases and is usually expressed as a number in relation to a base figure of 100, and Spanish ‘ES’ where the current month is expressed as 1 and preceding months as a multiplication factor. The type of index to be used is specified in SC.PARAMETER field INFL.INDX.METH.

Figure 7 - Example SC.PARAMETER record

For example the following transactions are made:

A purchase of 12000 shares is made at a cost of $15000 on 1st May 1999; a second purchase is made of 10000 shares at a cost of $16000 on 1st January 2000. A sale for 17000 shares is then made the proceeds of which are $25000 on the current business day.

When retrieving the inflation indexes from the COUNTRY or REGION tables using the ‘Spanish’ method the system will append the transaction year to the key before reading the data, for example a disposal transaction in 1999 for a customer with a RESIDENCE.REGION of ES01 will attempt to read the record keyed by ES01.1999 from the REGION table, if that fails then the key ES01 will be used. If the ‘Standard’ method is used then the transaction years will not be used to suffix the key, only the field from the COUNTRY record will be used.

Figure 8 - Example COUNTRY record

The above screenshot shows inflation indexes entered using the Standard method. Using the above screenshot the cost of the shares purchased on 1st May 1999 will be adjusted to (1 + (123.6 – 121.8)/121.8) * 15000 = 15221.70. The cost of the shares purchases on 1st January 2000 will be adjusted to (1 + (123.6 – 123.1)/123.1) * 16000 * 5000/10000 = 8032.48. This gives a total cost of $23254.18 giving a gain of $1745.82.

Figure 9 - Example COUNTRY record

The above record shows inflation indexes entered using the Spanish method. Using the above screenshot the cost of the shares purchased on 1st May 1999 will be adjusted to 1.23 * 15000 = 18450.00. The cost of the shares purchases on 1st January 2000 will be adjusted to 1.04 * 16000 * 5000/10000 = 8320.00. This gives a total cost of $26770 giving a loss of $1770.00.

TAPER.RELIEF

This application allows the T24 user to specify reduction percentages to be applied to a gain after any indexation has been applied.

Figure 10 - Example TAPER.RELIEF record

The above record will only apply to sale transactions made on or after 1st January 1999. The use of the date in the key allows for changes in the taper relief percentages over time. Only the first part of the key is specified in the CG.PARAMETER record, the system will automatically determine which record to use. The fields set in this record will apply a reduction of 10% to holdings held for at least 5 years but less than 10 years, a reduction of 15% will be applied to holdings held for at least 10 years but less than 20 years, holdings held for at least 20 years but less that 30 years will receive a 25% reduction. Holdings held for less than 5 years will receive no reduction. Holdings held for at least 30 years will receive a reduction percentage as determined by the user defined local subroutine. A user defined local subroutine can be used to calculate the reduction percentage, the subroutine name should be entered in the field REDUCT.PCT prefixed by a @ symbol. The subroutine must have 5 subroutine arguments, the first three are passed by the calling routine, these are the transaction base record, the multi-value position of the sale in the base record and the multi-value position of the purchase in the base record. The remained two arguments are reduction percentage, which should be returned by the local subroutine and an error message variable, which is reserved for future use. Holding periods can be specified as either months or year in field HELD.PERIOD.TYPE. Where the holding has been held for part of a period the fractional element can either be rounded up to 1 or down to 0 as specified in field HELD.PERIOD.ROUND. Whether a holding qualifies for taper relief can be specified using the fields PUR.QUAL.DATE and SALE.QUAL.DATE. If the field PUR.QUAL.DATE is populated then the purchase must be on or before the date specified, if the field SALE.QUAL.DATE is populated then the sale must be on or after the date specified. If both fields are populated then both the sale and the purchase must satisfy the conditions for the taper relief to be applied. If the field HELD.PERIOD.CUTOFF is used then the maximum holding period will be limited by this date. If the sale date is greater than the date in this field then the date in this field will be used when calculating the holding period. No taper relief will be applied if a loss is made on a transaction.

PORTFOLIO.GROUPING

This application allows the T24 user to group together the portfolios of one customer together for CGT purposes.

Figure 11 - Example PORTFOLIO.GROUPING record

The above record will maintain separate transaction base records for the customer 100112. However it is possible to set up the system to group all the customer portfolios together for CGT purposes.

Figure 12 - Example PORTFOLIO.GROUPING record

The above record will group all transactions from portfolios 200100-1 and 200100-2 together for CGT purposes. If the GROUP.NAME is set as ALL then only one group may be used, and any new portfolios must be added to the same group, the system will automatically add a new portfolios to the ALL group when the first transaction is made. If the ALL group is not used then the system will automatically add a new group for each new portfolio with it’s own group code to the PORTFOLIO.GROUPING record when the first transaction is made. The group code will be set as the portfolio code. If the T24 user does not want the system to automatically allocate portfolios to groups and set group names then they must set up or amend the PORTFOLIO.GROUPING record whenever a new record is added to SEC.ACC.MASTER before any transactions, SEC.TRADE or SECURITY.TRANSFER are made in that portfolio. Portfolios cannot be moved between groups or deleted from groups if there are positions in any securities for the portfolio concerned.

PORTFOLIO.GROUPING Set-up When the application is set-up for the first time the system will create PORTFOLIO.GROUPING records for each portfolio referenced in the CG.TXN.BASE. This set-up will be done as part of the conversion routine. The records will be set-up up using the CUSTOMER key, and each portfolio will be added with a GROUP.NAME that is the same as the SEC.ACC.MASTER key. The T24 user can let the system set-up these records as each new SEC.ACC.MASTER executes a transaction for the first time, the set-up will be identical, a new GROUP.NAME will be added to the PORTFOLIO.GROUPING record and it will be the same as the SEC.ACC.MASTER key. An override message will be displayed at transaction level. If the T24 user wishes to change this default action then before each SEC.ACC.MASTER records executes a transaction the PORTFOLIO.GROUPING record must be updated with the T24 users settings.

CG.TXN.RULES

This application is only used when the setting for field CG.BASE.UPDATE in SC.PARAMETER is set to RULES. It allows the user to specify an ‘event’ to be performed when a transaction updates the transaction base, it also allows the T24 user to specify which transaction types will update the transaction base.

Figure 13 - Example CG.TXN.RULES record

The application will allow setting up of records using either the transaction name, as set up in SC.TRANS.NAME, a transaction name and SUB.ASSET.TYPE Id or transaction name and SECURITY.MASTER Id. The record containing a SECURITY.MASTER Id will be used in preference to one with a SUB.ASSET.TYPE Id, which in turn will be used in preference to one containing just the transaction name.

Each record can specify a particular capital event-using field EVENT.TYPE. The value must be one of the following, • ACTION.WARRANT • BONUS.SHARE • BUY • CAPINCR.RIGHTS • CAPITAL.REDUCTION • CONVERSION • MERGER • REDEMPTION • RIGHTS • SEL • SPINOFF • SPLIT • STOCK.DIVIDEND • TAKE.OVER These events will produce the following capital event. It should be noted that there are no checks made between the origin of the transaction and the EVENT.TYPE, therefore it is possible to link say, a securities purchase to a corporate action type event such as a SPIN.OFF, in such cases the results will be unpredictable. It should also be noted that the EVENT.TYPE used in CG.TXN.RULES is not to be confused with the EVENT.TYPE defined in DIARY, which refers to a valid DIARY.TYPE. For an ENTITLEMENT, which will be used to update the CG.TXN.BASE the GC.TXN.RULES to be selected will be found from the ENTITLEMENT to the underlying DIARY to the underlying DIARY.TYPE to the underlying SC.TRANS.TYPE to the underlying SC.TRANS.NAME to the underlying CG.TXN.RULES. So a DIARY with any EVENT.TYPE (DIARY.TYPE) may be linked to any of the CG.TXN.RULES EVENT.TYPE's listed above. Another point worth mentioning here is that when using a DIARY.TYPE which does not create any cash posting naturally i.e. only securities are produced as in SPINOFF, the field UPDATE.NOSTRO must be set to NO in order for tax postings to be created for the capital gains.

EVENT.TYPE: ACTION.WARRANT The warrant will be disposed of and the new shares added to the transaction base at a cost of exercising the warrant plus the cost of the warrants. The warrants will be disposed of at cost giving a capital gain of zero. If the warrant is lapsed then no new shares will be created.

EVENT.TYPE: BONUS.SHARE If the field UPD.ORIG.NOM is Y then: If the bonus shares are the same as the original security then the new shares will be spread over all the open transactions in proportion to the number of shares in the active CG.NOMINAL already on the base. If the bonus shares are in a new security or securities then the new shares will be added to a new transaction base record and the cost apportioned between the transaction base records in proportion

to the number of shares. If the field ORIG.ACQ.DT is Y then the new shares will be added to the new base using the dates of the original acquisitions, otherwise the new shares will be added using the PAY.DATE from the DIARY record. If the field UPD.ORIG.NOM is not Y then any new shares will be added as a single transaction using the PAY.DATE from the DIARY record.

EVENT.TYPE: BUY A transaction will be added to the base using the TRADE.DATE field if transaction originates from either SEC.TRADE or SECURITY.TRANSFER, or PAY.DATE if the transaction originates from DIARY. If the transaction originates from SEC.TRADE and the field CUST.NO.NOM contains more than one sub-value then one transaction will be added for each of these sub-values.

EVENT.TYPE: CAPINCR.RIGHTS If the transaction originates from a DIARY the CG.TXN.BASE for the rights security will be updated with the appropriate number of rights for zero cost with an acquisition date equal to the ex date of the DIARY. If the transaction originates from SEC.TRADE and the transaction is a purchase/sale for rounding (achieving the correct number rights to enable take up of a whole number of new securities), indicated by ODD.RTS.CGT field (will be Y), in the SEC.TRADE and RSTL.UPDT.ORIG is Y and the transaction is a sale or the transaction is a purchase then the costs of the purchase/sale will be added or subtracted to/from the transaction base of the security that created the rights entitlement. At the same point the fields ODD.RTS.SAM and ODD.RTS.BAM in the ENTITLEMENT record will be adjusted by the nominal amount purchased or sold. The transaction will then be added to the rights security transaction base with the cost adjusted by the amount distributed to the original security transaction base. Otherwise, ODD.RTS.CGT NOT equal to Y, the transaction will be added to the base as either a BUY or SEL EVENT.TYPE transaction. If the rights are exercised therefore the transaction originates from DIARY then the rights securities position will become zero and the new security or securities position will be created. If the new security is the same as the security that gave rise to the corporate action then the new shares will either be distributed over the existing transactions, UPD.ORIG.NOM = Y, or added as a single new transaction with an acquisition date equal to the payment date of the DIARY. If the new security is different from the security that gave rise to the corporate action then a new transaction base will be created with the cost apportioned between the transactions bases. The new base will use the dates from the original acquisitions, where an amount remains unsold.

EVENT.TYPE: CAPITAL.REDUCTION This event will take the cash repaid to the customer and reduce the costs of the transactions in the base by an amount proportional to the CG.NOMINAL.

EVENT.TYPE: CONVERSION This event will remove the holdings from the original security and create new base records for each of the securities resulting from the conversion.

The cost or proceeds of the movement out of the original security will be the market value of the new security based on the NEW.MKT.PRC field from the DIARY, the conversion premium and accrued interest can be included in this disposal cost or the acquisition cost using the flags CONV.INCL.ACCR and CONV.INCL.PREM. Therefore there will be a capital gain/loss calculated which may be material if different from the original cost. You can of course suppress the tax posting by setting the CALC.TAX field to NO on the CG.TXN.RULES application record. The cost of the new securities will be the calculated using the new market price, from DIARY field NEW.MKT.PRC, and depending on the settings of CONV.INCL.ACCR and CONV.INCL.PREM, the original accrued interest and conversion premium can be added to this cost.

EVENT.TYPE: MERGER This event will close down the transaction base for the original security and create new base records for the new security or securities. There are two types of MERGER processing available, with or without Fiscal effect, this is determined by the flag FISCAL.EFF. Where FISCAL.EFF is not Y the old security will be removed at the original acquisition cost, the new security or securities will be added with the original acquisition cost allocated proportionally. Where FISCAL.EFF is Y then the flags MKT.VAL.OLD, MKT.VAL.NEW, MKT.VAL.HIGH or MKT.VAL.LOW will be used to determine the costs to be used. Only one of these flags can be specified. For example, if MKT.VAL.HIGH is set then the old security will be removed and the cost will be the highest of the old security or the new security or securities. The new securities will be added using the same cost, spread proportionally is required. When calculating the costs the fields OLD.MKT.PRC and NEW.MKT.PRC from the DIARY record will be used.

EVENT.TYPE: REDEMPTION A disposal transaction will be added to the base using the TRADE.DATE field if transaction originates from either SEC.TRADE or SECURITY.TRANSFER, or PAY.DATE if the transaction originates from DIARY. If the transaction originates from SEC.TRADE and the field CUST.NO.NOM contains more than one sub-value then one transaction will be added for each of these sub-values. The disposal proceeds will be the redemption proceeds from the SECURITY.TRANS record derived from the ENTITLEMENT record.

EVENT.TYPE: RIGHTS A transaction will be added to the base using the TRADE.DATE field if transaction originates from either SEC.TRADE or SECURITY.TRANSFER, or PAY.DATE if the transaction originates from DIARY. If the transaction originates from SEC.TRADE and the field CUST.NO.NOM contains more than one sub-value then one transaction will be added for each of these sub-values. The rights security will be disposed of and the new security or securities added to the transactions base. This functionality was superceded by the event type CAPINCR.RIGHTS which is more comprehensive.

EVENT.TYPE: SEL A transaction will be added to the base using the TRADE.DATE field if transaction originates from either SEC.TRADE or SECURITY.TRANSFER, or PAY.DATE if the transaction originates from

DIARY. If the transaction originates from SEC.TRADE and the field CUST.NO.NOM contains more than one sub-value then one transaction will be added for each of these sub-values.

EVENT.TYPE: SPINOFF There are two types of SPINOFF with or without fiscal effect as defined by the FISCAL.EFFECT field on CG.TXN.RULES. Where the flag is set to Y the original securities will be removed from its CG.TXN.BASE record at the sum of the market valuations of the original and new securities. The original securities will be reacquired at its own market valuation and the new securities will be acquired at its own valuation. Where the flag is not set to Y the original securities will be disposed of from its CG.TXN.BASE at its original cost. The reacquisition cost and acquisition costs of the original and new securities will be the original cost split in proportion to the market valuation of the original and new securities inferred by the OLD.MKT.PRC and NEW.MKT.PRC fields from the DIARY.

EVENT.TYPE: SPLIT This event will update the active CG.NOMINAL fields on the CG.TXN.BASE record. It will spread the new split position across all the active CG.NOMINAL amounts in the proportion of the previous CG.NOMINAL divided by the total of the previous active CG.NOMINALS.

EVENT.TYPE: STOCK.DIVIDEND This event will either update the original CG.NOMINAL fields in the transaction base, if UPD.ORIG.NOM is Y, or add a new transaction to the base otherwise. The cost of the new securities will be determined by the setting of the field MKT.VAL.NEW. If the field UPD.ORIG.NOM is Y then the cost of the new securities will be distributed over the active CG.NOMINAL positions. Where the security derived from the stock dividend is different from the original security a new transaction base record will be created.

EVENT.TYPE: TAKE.OVER A transaction will be added to the base using the TRADE.DATE field if transaction originates from either SEC.TRADE or SECURITY.TRANSFER, or PAY.DATE if the transaction originates from DIARY. If the transaction originates from SEC.TRADE and the field CUST.NO.NOM contains more than one sub-value then one transaction will be added for each of these sub-values. The original security will be disposed of and the new security or securities added to the transaction’s base. The costs used will be those on each of the SECURITY.TRANS records, field GROSS.AMT.SEC.CURR. This is the original functionality, which preceded CG.TXN.RULES and it is recommended that MERGER should be used for corporate actions, which require more flexible TAKEOVER functionality. The field CALC.TAX is used to trigger the calculation of capital gains tax. Tax will be calculated if set to Y, otherwise the transaction will not generate any tax accounting entries. The field MANUAL.ALLOWED is used to limit whether the transaction type can be used in CG.MANUAL.INPUT. It may only be set to Y if the EVENT.TYPE is either BUY or SEL. The field UPDATE.METHOD can be set to either ONLINE or BATCH. When set to BATCH all updates to the transaction base, CG.TXN.BASE, and tax calculations will take place during a Close of Business batch process and will only be performed for authorised transactions. If set to ONLINE

then the transaction base will be updated when the transaction is validated, i.e. at unauthorised status, and the tax calculated at the same time. The tax postings at this stage will be NAU entries or forward value dated entries and they will be fully posted when the underlying records are authorised if the system date is equal to or greater than the value date of the transaction. In the case of forward value dated entries they will be posted and the CG.TXN.BASE will be updated in the start of day processing in the Close of Business routine. For instance a transaction value dated the 20th will update the base in the Close of Business routine for the 19th, which processes the start of day routines for the 20th. The STMT.ENTRY id’s will then be recorded on the CG.TXN.BASE record in the STMT.NOS and the authorised underlying record. At the same time the TAX.STATUS field in the CG.TXN.BASE will be changed to POSTED. It should be noted that the only ENTITLEMENT records that update the transaction base at unauthorised stage are Rights type corporate actions where the new Rights securities will be added to the base with an acquisition date equal to the ex date of the DIARY. Specifically those DIARY.TYPE records with field RIGHTS = Y. It should also be noted that setting the method to ONLINE may cause a high number of history records to be stored, as each change to an underlying transaction in the base and it’s subsequent authorisation will update the CURR.NO of the record.

CG.MANUAL.INPUT

This application is only used when the setting for field CG.BASE.UPDATE in SC.PARAMETER is set to RULES. When using this application the amendments to the transaction base will produce no accounting entries. This application will allow the T24 user to either enter a capital gains transaction base for a customer, or correct positions within the base. The CG.MANUAL.INPUT records will not create SECURITY.TRANS records or update the SECURITY.POSITION records therefore to create a transaction history for a position for a newly acquired customer a SECURITY.TRANSFER in should be used with a SC.TRANS.NAME not specified in the CG.TXN.RULES application, which will not therefore update the CG.TXN.BASE. When using CG.MANUAL.INPUT to create the history you may input the transaction id of the SECURITY.TRANS including the suffix (i.e. SCTRSC0005300001.1) into the TRANSACTION.ID field. If the id does not already exist on the CG.TXN.BASE the following fields will automatically be populated with the following fields: - PORTFOLIO.NO GROUP.NAME SECURITY.NO SECURITY.CCY MASTER.TRD.NOMINAL The following multi-valued fields must be populated to reflect the trade history comprising the nominal amount displayed in MASTER.TRD.NOMINAL: - TRADE.DATE.TIME TXN.TYPE TRD.NOMINAL TRD.VALUE ACCRUED.INT EXPENSES If you try you commit the record when the sum of the TRD.NOMINAL fields is not equal to the MASTER.TRD.NOMINAL an error message will be displayed. Each multi-valued set will be added to

the CG.TXN.BASE record when the CG.MANUAL.INPUT record is authorised. The CG.TXN.BASE position nominal will now be in line with the SECURITY.POSITION. You can of course create a CG trade history by adding a CG.MANUAL.INPUT record not connected to an underlying transaction but this is likely to put your SECURITY.POSITION and CG.TXN.BASE position out of synchronisation.

Figure 14 - Example Transfer in without transaction base update

Figure 15 - Example CG.MANUAL.INPUT - Data Take-on

Figure 16 - Example CG.MANUAL.INPUT - Data Take-on

Figure 17 - Example CG.TXN.BASE - Data Take-on

Figure 18 - Example CG.TXN.BASE - Data Take-on

Figure 19 - Example CG.TXN.BASE - Data Take-on

Figure 20 - Example CG.TXN.BASE - Data Take-on

It is recommended that if this application is to be used as a correction tool it should only be as a last resort. In such cases the capital gains transaction base will no longer be consistent with the security transactions that built the base originally. Where possible the original securities transactions should be corrected themselves. If it is to be used the TRANSACTION.ID field should be populated and if this id is found to exist on the CG.TXN.BASE record all the relevant fields will be populated allowing update. If the transaction position has been sold or the transaction is a debit transaction then it is not possible to adjust the details. When the CG.MANUAL.INPUT record is authorised the CG.TXN.BASE record will be changed to reflect the changes made on the CG.MANUAL.INPUT record. If the TRD.NOMINAL field is adjusted the TRD.NOMINAL.ADJ field will become populated. All other fields will be updated like for like.

Figure 21 - Example - Manually adjusted transaction

Batch Processing

Batch updates of the transaction base, CG.TXN.BASE, and batch calculation of the tax due on the gains are performed by two batch jobs. They are SC.UPDATE.CG.BASE and SC.CALC.CG.TAX respectively. These should be added to an existing update batch, such as SC.BATCH.APP, or to an equivalent new batch. Batch processing is only supported when the update method is RULES, as set in SC.PARAMETER field CG.BASE.UPDATE. When updating the base with new transactions all records will be selected from F.SEC.TRADES.TODAY and each record processed in turn. This file contains the list of authorised transactions that have updated a SECURITY.POSITION. Any records which bear changes from already authorised transactions will result in the old details being removed from the transaction base and the new details added. Additionally any record in the transaction base that has since been reversed will be removed from the transaction base. It should however be noted that not all corporate actions can be reversed in this manner. Only those events that add a transaction can be reversed, events such as a Bonus where the entitlement is distributed over all open transactions cannot be reversed. The reversible EVENT.TYPE’s are TAKE.OVER, CONVERSION, MERGER, SPINOFF, REDEMPTION, RIGHTS, STOCK.DIVIDEND, ACTION.WARRANT and CAPINCR.RIGHTS (where the new securities are separate transactions on the base.). If an event cannot be reversed then the application CG.MANUAL.INPUT can be used to manually effect the reversal. Tax will be calculated and posted on all transactions in the base where the field TAX.STATUS is TO_BE_CALC and the value date of the underlying transaction is equal to or less than the current start of day date. If a gain has been made then the TAX.STATUS will be set to POSTED and the field

STMT.NOS updated with the Id’s in STMT.ENTRY. When a loss is made no tax is due and TAX.STATUS will remain as TO_BE_CALC.