2. Allocation Process

After an investor transaction is authorized in the system, the units due to the investor in respect of the transaction must be accrued into the investor’s account balance. All applicable charges must be applied in the process of this accrual.

Also, the data stores maintained for the fund must be updated with the units accrual.

The process of accruing the units in this manner is known as allocation. The units in respect of an investor transaction request are “allocated” in this process.

The allocation process is an integral part of the End of Day processes at the Fund Manager component. When the operator user at the Fund Manager executes the End of Day processes, any transaction requests that are eligible for allocation on the given business day are picked up for allocation, and the allocation process allocates the units in respect of each of them automatically.

For funds in which on-line allocation is available as defined in the Transaction Processing Rules, the allocation processes for any transactions into such funds are run upon authorization of the transaction.

Depending upon the necessity, the operator user at the Fund Manager component could also execute the allocation process for any type of transaction manually, for a fund or all funds, by choosing the appropriate menu item from the End of Day menu category.

This chapter describes the process of allocation, as well as how transactions are picked up for allocation by the allocation process on any business day. This chapter is intended for the following persons:

Typically, these are the only users or user groups that are authorized to perform these activities. No other user or group will be able to access the End of Day processes menu category in the Fund Manager component.

This chapter is divided into the following sections:

This chapter must be used in conjunction with the chapters ‘Setting up Funds’ and ‘Setting up Loads’ in this User Manual.

This chapter contains the following sections:

2.1 Transactions for Automatic Allocation

This section contains the following topics:

2.1.1 Allocating Transactions Automatically

The transactions that are automatically picked up by the End of Day processes for allocation on any business day include:

Further, the transactions could be:

Transactions with mode of payment as check / credit card/demand draft / transfer, where the payment instrument has been cleared and the clearing has been authorized on the given day.

In a fund, if allocation of check / credit card / transfer payment transactions is designated to be treated on par with cash payment transactions, then the units in respect of transactions with these payment modes are allocated on a provisional basis on the same business day, even if the instrument is not cleared on that day.

The provisionally allocated units are then moved to the unit holder’s confirmed unit balance on the day the instrument is cleared, and the clearing authorized.

Further, if so designated, the price reckoned for allocation of check payment transactions is the prevalent price on the date of clearing.

Price Lag

For both cash-based and non-cash based transactions, if a price lag has been defined for the transaction type in the Transaction Processing Rules, the price lag days are considered based on either the fund calendar or the actual calendar, depending upon the Price Lag Basis specification in the Transaction Processing Rules.

Allocation Lag

For all transactions, if an allocation lag has been defined for the transaction type in the Transaction Processing Rules, the allocation lag days are considered based on either the fund calendar or the actual calendar, depending upon the Allocation Lag Basis specification in the Transaction Processing Rules.

To understand the allocation lag, consider the following example:

The GROWTH fund has an allocation lag of 2 for IPO transactions. This means that the system should allot IPO transactions that are entered (or which have been entered with the transaction date) 2 days before the current system date. The allocation lag days are considered as of the Fund Calendar or the actual calendar, depending upon the allocation lag calendar basis defined in the Transaction Processing Rules for IPO transactions for the fund.

If the current system date is 15th of December 2002 and the allocation lag calendar basis is ‘actual calendar’, then all IPO transactions of GROWTH fund that were entered on or before 13th of December 2002 will be allotted. If the allocation lag for IPO Subscription transactions were 3 for GROWTH fund all transactions on or before 12th of December 2002 would be allotted.

2.1.2 Manual Allocation through End of Day Menu

You can use the ‘Allocation Detail’ screen to trigger manual allocation of units. You can invoke this screen by typing UTDALLOC’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

As stated earlier, depending upon the necessity, the operator user at the Fund Manager component could also execute the allocation process for any type of transaction manually, for a fund or all funds, by clicking the appropriate menu item from the End of Day menu category.

In the Allocation screen, you can trigger the allocation process:

AMC ID

Alphanumeric; 100 Characters; Mandatory

Specify the AMC ID. Alternatively, you can select the AMC ID from the option list. The list displays all the valid AMC ID maintained in the system.

AMC Name

Display

The system displays the AMC name for the selected AMC ID.

AMC / Agent Code

Alphanumeric; 12 Characters; Mandatory

Specify the AMC or agent code. Alternatively, you can select the AMC or agent code from the option list. The list displays all the valid AMC or agent codes maintained in the system.

AMC / Agent Name

Display

The system displays the AMC or agent name for the selected AMC or Agent code.

Fund ID

Alphanumeric; 6 Characters; Mandatory

Specify the fund ID. Alternatively, you can select the fund ID from the option list. The list displays all the valid fund ID maintained in the system.

Transaction Type

Alphanumeric; 3 Characters; Mandatory

Specify the transaction type. Alternatively, you can select the transaction type from the option list. The list displays all the valid transaction type maintained in the system.

Transaction Name

Display

The system displays the transaction name for the selected transaction type.

Back Dated?

Optional

Select if allocation is back dated or not from the drop-down list. The list displays the following values:

Submit For

Optional

Select submit for details from the drop-down list. The list displays the following values:

Click ‘Display Fund’ button to view the fund details.

Fund ID

Display

The system displays the fund ID.

Fund Name

Display

The system displays the fund name.

Fund Identification Number

Display

The system displays the fund identification number.

Select

Optional

Select yes or no from the drop-down list. The list displays the following options:

Select the transaction type in the Transaction Code field. You can select the ‘ALL’ option to allocate transactions of all types. A list of funds is also displayed. You can select a fund in the list by checking the box alongside it. To select all funds, click the Select All link. To indicate allocation of backdated transactions, check the Back Dated box.

When you have chosen the type of transaction to be allocated, and the fund, click ‘Execute’ button. The job is submitted and the Asynchronous Process screen is opened. This screen indicates the current status of the allocation process. When complete, the system displays a completion message in the Asynchronous Process screen.

2.1.3 IPO Transactions Allocation

To trigger the allocation of unallotted IPO transactions on a business day, select the IPO option in the Allocation screen. Choosing this option will also trigger the allocation process, to allocate units in respect of unallotted IPO transactions, which fall within the allocation lag period defined for the fund in which the transaction was put through, in the Transaction Processing Rules.

Also, choosing this option will trigger the allocation process to allocate units in respect of IPO check payment transactions, in funds wherein the allocation of check payment transactions is not treated on par with cash payment transactions.

Further, you choose this option to allocate such transactions for which the check has been cleared on the application date, and the clearing status has been updated and authorized as “cleared”, on the application date.

The allocation process is exactly the same as that described in the section ‘The process of allocation’ that is found later in this chapter.

Certificate details

If the fund is scrip-based or if the unit holder requests for certificates in case of certificate optional funds, then the Certificate Numbers are also allotted for the IPO Subscription transaction. The certificates are issued based on the certificate denomination details defined in the Shares Characteristics, or as required by the unit holder. DNR numbers are also allotted for the generated certificates in case of non-fractional funds.

Amended IPO transactions

If an amended IPO Subscription is allocated, then the following changes are reflected after the allocation - first, the changes affected by the original IPO Subscription are reversed, and then the currently amended IPO Subscription is reallocated.

Reflection of allocated units in the system database

If the IPO transaction is successfully allocated through this option, the changes are reflected in the following data stores in the database:

If any of these counter limits is exceeded or if any of the fund rules set up at the Fund Manager are violated then an error is logged against the subscription transaction.

Confirmation of the IPO Subscription is made after the allocation is successfully completed.

Note

Only reversal is allowed for certificate based IPO Subscription transaction.

2.1.4 Subscription Allocation

To trigger the allocation of unallotted subscription transactions on a business day, select the Subscription option in the Allocation screen. Choosing this option will also trigger the allocation process, to allocate units in respect of unallotted subscription transactions, which fall within the allocation lag period defined for the fund in which the transaction was put through, in the Transaction Processing Rules.

Also, choosing this option will trigger the allocation process to allocate units in respect of subscription check payment transactions, in funds wherein the allocation of check payment transactions is not treated on par with cash payment transactions.

Further, you choose this option to allocate such transactions for which the check has been cleared on the application date, and the clearing status has been updated and authorized as “cleared”, on the application date.

Choosing this option will also trigger the allocation of investment (both initial and additional investment) IRA transactions into the fund.

While allocating subscription transactions, the system will pick the exchange rate defined by you in the ‘Exchange Rate Maintenance Detail’ screen for the FX Deal Date and FX Value Date combination. If this combination is unavailable, the allocation will fall through. However, for allocation projection, the system will use the FX Spot Rate.

For example, assume that on January 19, 2010, a user has input both spot and forward rates for January 20, January 21 and January 22, 2010. If the FX Deal date for the transaction is January 19, 2010 and the FX Value Date is January 21, 2010, then for both allocation and projection the exchange rate with deal date as 19 January and value date as 21 January will be used.

If a transaction has FX Deal date as January 19, 2010 and FX Value Date as January 23, 2010, the allocation will not happen since the exchange rate for the combination is not available in the system. However, the allocation projection will use the spot rate (FX Deal and FX Value dates as on January 19, 2010).

The allocation process is exactly the same as that described in the section ‘The process of allocation’ that is found later in this chapter.

Certificate details

If the fund is scrip-based or if the unit holder requests for certificates in case of certificate optional funds, then the Certificate Numbers are also allotted for the subscription transaction. The certificates are issued based on the certificate denomination details defined in the Shares Characteristics, or as required by the unit holder. DNR numbers are also allotted for the generated certificates in case of non-fractional funds.

Amended subscription transactions

If an amended subscription is allocated, then the following changes are reflected after the allocation - first, the changes affected by the original subscription are reversed, and then the currently amended subscription is reallocated.

Reflection of allocated units in the system database

If the subscription transaction is successfully allocated through this option, the changes are reflected in the following data stores in the database:

If any of these counter limits is exceeded or if any of the fund rules set up at the Fund Manager are violated then an error is logged against the subscription transaction.

Confirmation of the subscription transaction is made after the allocation is successfully completed.

Note

Only reversal is allowed for certificate based subscription transaction.

2.1.5 Redemption Allocation

To trigger the allocation of unallotted or partially allotted redemption transactions on a business day, select the Redemption option in the Allocation screen.

For funds in which the check writing facility has been allowed, choosing this option will also allocate any redemption transactions in respect of redemption checks issued using the check writing facility availed by a unit holder in the fund.

If the fund is part of a portfolio of a product, choosing this option will also trigger the allocation of withdrawal (both partial and complete) IRA transactions into the fund.

The allocation process is exactly the same as that described in the section ‘The process of allocation’ that is found later in this chapter.

While allocating redemption transactions, the system will pick the exchange rate defined by you in the ‘Exchange Rate Maintenance Detail’ screen for the FX Deal Date and FX Value Date combination. If this combination is unavailable, the allocation will fall through. However, for allocation projection, the system will use the FX Spot Rate.

For more details refer the ‘Subscription Allocation’ section specified earlier in this manual.

Certificate details

If the fund is scrip based or if the unit holder redeems out of issued balance in certificate optional funds, then Certificate Numbers and DNR numbers are also affected by the redemption transaction. The amount of the certificates entered should be greater or equal to the units that have to be redeemed. In case the units are greater only one of the certificates can be redeemed partially.

Amended redemption transactions

If an amended redemption is allocated then the following changes are reflected after the allocation - first, the changes affected by the original redemption are reversed and the current amended redemption is reallocated.

Reflection of allocated units in the system database

If the redemption transaction is successfully allocated through this menu item, the changes are reflected in the following data stores in the database:

If any of these counter limits is exceeded or if any of the fund rules set up at the Fund Manager are violated then an error is logged against the redemption transaction. If the redeemable units for the transaction is greater than the unit holder balance in the fund then the transaction is rejected by the allocation process.

Confirmation of the redemption transaction is made after the allocation is successfully completed.

Note

Allocation of check writing transactions

When a check redemption transaction is allocated, the system validates the following:

If the allocation fails due to failure of either validation mentioned above, or due to any other error, the check is marked with the status ‘Allocation Failed’. The details of the failure of the allocation are recorded in the system database. You can set up a report through the Interface Definition, to view or print the details.

In the event of failure of allocation of any check redemption transactions during the course of a business day, the system displays a message indicating the same, and prompting you to obtain a report, during the pre-end of day checks.

Allocation of amended check writing transactions

If a check redemption transaction is amended before allocation, the validations made during allocation of such transactions, which are mentioned in the previous section, are performed by the system as usual.

If amended after allocation, the status of the check is marked as “Processed”, and the validations during allocation are performed, as usual.

If the amount of the transaction is amended to a ‘zero’ or null value, the status of the check is marked as ‘Invalid Amt’, during allocation.

2.1.6 Switch Allocation

To trigger the allocation of unallotted or partially allotted switch transactions on a business day, select the Switch option in the Allocation screen.

The allocation process is exactly the same as that described in the section ‘The process of allocation’ that is found later in this chapter.

In the case of switch allocation, the following steps are followed:

  1. First a Switch From allocation is done for the fund from where the units are being switched for the given unit holder. This allocation considers the switch from as a normal redemption transaction by net amount / units.
  2. Then, a Switch To allocation is made for the fund into which the units are being switched for the given unit holder. This allocation is done on the basis of a normal subscription allocation by gross amount.
  3. Both the above transactions are system generated based on the switch transaction that has been entered into by the user.

If the switch transaction being allocated is a pseudo-switch, the system will pick the exchange rate defined by you in the ‘Exchange Rate Maintenance Detail’ screen for the FX Deal Date and FX Value Date combination. If this combination is unavailable, the allocation will fall through. However, for allocation projection, the system will use the FX Spot Rate.

For more details refer the ‘Subscription Allocation’ section specified earlier in this manual.

Certificate details

If the fund is scrip based or if the unit holder switches out of issued balance in certificate optional funds then Certificate Numbers and DNR numbers are also affected by the switch transaction. The amount of the certificates entered for the switch should be greater or equal to the units that have to be redeemed from the switched out fund. In case the units are greater only one of the certificates can be switched partially.

Amended switch transactions

If an amended switch is allocated then the following changes are reflected after the allocation - first, the changes affected by the original switch are reversed and the current amended switch is reallocated.

Reflection of allocated units in the system database

If the switch transaction is successfully allocated through this menu item, the changes are reflected in the following data stores in the database:

If any of these counter limits is exceeded or if any of the fund rules set up at the Fund Manager are violated then an error is logged against the switch transaction. If the switched units for the transaction is greater than the unit holder balance in the fund then the transaction is rejected by the allocation process.

Confirmation of the switch transaction is made after the allocation is successfully completed.

Note

Only reversal is allowed for certificate based switch transaction.

2.1.7 Transfer Allocation

To trigger the allocation of unallotted transfer transactions on a business day, select the Transfer option in the Allocation screen.

The allocation process is exactly the same as that described in the section ‘The process of allocation’ that is found later in this chapter.

Certificate details

If the fund is scrip based or if the unit holder transfers out of issued balance in certificate optional funds, the certificates are reissued in the name of the unit holder to whom it is being transferred if the transferee opts for certificates. The reassigned certificates can be printed using the Certificate Printing option in the Browser menu.

Amended transfer transactions

If an amended transfer is allocated then the following changes are reflected after the allocation - first, the changes affected by the original transfer are reversed and the current amended transfer is reallocated.

Reflection of allocated units in the system database

If the transfer transaction is successfully allocated through this menu item, the changes are reflected in the following data stores in the database:

If any of these counter limits is exceeded or if any of the fund rules set up at the Fund Manager are violated then an error is logged against the transfer transaction.

Confirmation of the transfer transaction is made after the allocation is successfully completed.

Note

Only reversal is allowed for certificate based transfer transaction.

2.1.8 Block Allocation

To trigger the allocation of unallotted block transactions on a business day, select the Block option in the Allocation screen.

The allocation process is exactly the same as that described in the section The process of allocation that is found later in this chapter.

Certificate details

If the fund is scrip based or if the unit holder blocks units out of issued balance in certificate optional funds, then the certificates are marked as blocked and cannot be used for further transaction until they are unblocked.

For certificate option funds, where certificates are designated as required for block transactions in the fund rules, the allocation of the block transaction will result in certificate generation.

Reflection of allocated units in the system database

If the block transaction is successfully allocated through this menu item, the changes are reflected in the following data stores in the database:

If any of these counter limits is exceeded or if any of the fund rules set up at the Fund Manager are violated then an error is logged against the block transaction.

Confirmation of the block transaction is made after the allocation is successfully completed.

Note

Amendment of a block transaction is not allowed.

2.1.9 Unblock Allocation

To trigger the allocation of unallotted unblock transactions on a business day, select the Unblock option in the Allocation screen.

The allocation process is exactly the same as that described in the section ‘The process of allocation’ that is found later in this chapter.

Certificate details

If the fund is scrip based or if the unit holder unblocks units out of issued balance in certificate optional funds, then the certificates are marked as unblocked and can be used for further transaction.

For certificate option funds, where certificates are designated as required for block transactions in the fund rules, the allocation of the block transaction will result in certificate generation.

Reflection of allocated units in the system database

If the unblock transaction is successfully allocated through this menu item, the changes are reflected in the following data stores in the database:

If any of these counter limits is exceeded or if any of the fund rules set up at the Fund Manager are violated then an error is logged against the unblock transaction.

Confirmation of the unblock transaction is made after the allocation is successfully completed.

Note

Amendment of an unblock transaction is not allowed.

2.1.10 Consolidation Allocation

To trigger the allocation of unallotted consolidation transactions on a business day, select the Consolidation option in the Allocation screen.

The allocation process is exactly the same as that described in the section ‘The process of allocation’ that is found later in this chapter.

Certificate details

The certificate numbers are also affected by the consolidation transaction. The certificates are consolidated based on the certificate denomination details defined in the fund rules or as requested by the unit holder and a single certificate is issued for the units consolidated.

Reflection of allocated units in the system database

If the consolidation transaction is successfully allocated through this menu item, the changes are reflected in the following data stores in the database:

If any of these counter limits is exceeded or if any of the fund rules set up at the Fund Manager are violated then an error is logged against the consolidation transaction.

Confirmation of the consolidation transaction is made after the allocation is successfully completed.

Note

Amendment of a consolidation transaction is not allowed.

2.1.11 Split Allocation

To trigger the allocation of unallotted split transactions on a business day, select the Split option in the Allocation screen.

The allocation process is exactly the same as that described in the section ‘The process of allocation’ that is found later in this chapter.

Certificate details

The certificate numbers and DNR numbers are also affected by the split transaction. The certificates are issued based on the certificate denomination details as defined in the fund rules or as requested by the unit holder. Now the single certificate will be split into multiple ones based on the denomination.

Reflection of allocated units in the system database

If the split transaction is successfully allocated through this menu item, the changes are reflected in the following data stores in the database:

If any of these counter limits is exceeded or if any of the fund rules set up at the Fund Manager are violated then an error is logged against the split transaction.

Confirmation of the split transaction is made after the allocation is successfully completed.

Note

Amendment of a split transaction is not allowed.

2.1.12 Reissue Allocation

To trigger the allocation of unallotted reissue transactions on a business day, select the Reissue option in the Allocation screen.

The allocation process is exactly the same as that described in the section ‘The process of allocation’ that is found later in this chapter.

Certificate details

The certificate numbers and DNR numbers are also affected by the reissue transaction. The certificates are reissued based on the certificate denomination details as defined in the fund rules or as requested by the unit holder, or as per the earlier issue.

Reflection of allocated units in the system database

If the reissue transaction is successfully allocated through this menu item, the changes are reflected in the following data stores in the database:

If any of these counter limits is exceeded or if any of the fund rules set up at the Fund Manager are violated then an error is logged against the reissue transaction.

Confirmation of the reissue transaction is made after the allocation is successfully completed.

Note

Amendment of a reissue transaction is not allowed.

2.1.13 Backdated Transactions Allocation

To allocate transactions that have backdating allowed as defined in the fund rules for the fund in which the transaction is being put through, select the Back Dated box in the Allocations screen.

All the transactions that have been entered into on the current application date with transaction date earlier than the same can be allocated through this function. The date of transaction should be within the limit specified for back dating as defined in the Transaction Processing Rules for the fund, or as set up for the agency branch / transaction type in the backdating table. This will take the transaction price of that date as effective for the given transaction.

The allocation process is exactly the same as that described in the section ‘The process of allocation’ that is found later in this chapter.

The allocation procedure is the same as the normal allocation process for the given transaction type. All the updating will be effected as of the date of allocation for the given transaction.

2.2 Allocation of Redemption /Switch Transactions with Capital Gains Tax

This section contains the following topics:

2.2.1 Capital Gains Tax as a post-allocation load in the system

You can define the Capital Gains Tax as a load in the system, through the Load Maintenance screen, in the Maintenance menu category of the Fund Manager component. You must then associate the load with the funds for which capital gains tax must be deemed as applicable, through the Fund Load Setup screen in the Data Entry menu category of the Fund Manager component.

The Capital Gains Tax is computed and deducted at source from the Redemption or Switch out proceeds, and the balance paid out as the final redemption or switch out amount payable to the investor.

The capital gains from a redeemed or switched transaction is computed in the system as the difference between the buying price of the subscription transaction that is redeemed, and the selling price of the redemption or switched transaction.

The buy price is computed as the sum of actual subscription amount and the loads (typically commissions, entry fees, initial charges and so on as applicable).

The sell price is computed as the actual redemption amount (and, if the investor chooses to redeem by units, the product of number of units applied for and the base price for the transaction) from which all the loads (exit fees, and so on, as applicable) have been deducted.

The following empirical expressions could be considered:

Capital Gains = Selling Price – Buying Price, where

Selling Price = Actual Redemption Amount – All applicable exit charges

And

Buying Price = Subscription Amount + All applicable initial charges and commissions

A database (backend) procedure in the system computes the Capital Gains applicable for each redemption or switch transaction after it is allocated.

The capital gains tax applicable on the computed capital gains is calculated, and the same is reduced from the net amount that proceeds from the redemption or switch transaction to the unit holder.

In the following transaction cycles, that involve more than a single subscription – redemption transaction scenario, capital gains tax is calculated for each individual leg and then the sum of all the computed tax values is reduced from the net proceeds from each redemption transaction.

For switch transactions, as shown in the example, the Capital Gains Tax is deducted in a manner similar to that in redemption transactions. The switch is considered as a redemption transaction from one fund and subscription into another. Therefore, the relevant acquisition cost of the subscription is from the switched out amount to arrive at the Capital Gains. The associated Capital Gains Tax is reduced from the switched out proceeds to arrive at the switched in amount. This is reckoned as the subscription amount in the switched in fund.

2.2.2 Indexation for Capital Gains Tax

The unit holder may opt for indexation to be applicable to capital gains computations. If so, you can indicate it in the unit holder account profile.

The capital gains from a redeemed or switched transaction is computed in the system as the difference between the buying price of the subscription transaction that is redeemed, and the selling price of the redemption or switched transaction.

Indexation involves a certain factor being applied on the capital gains, so as to arrive at the basis amount on which the capital gains tax is computed.

The basis, upon which the capital gains tax is applied, is computed using the empirical expressions:

For capital gains loads on gross amount, as specified in the Fund Load Setup,

 

For capital gains loads on net amount, as specified in the Fund Load Setup,

 

Where,

2.2.2.1 Applying Indexation

To configure the system to apply indexation for the computation of capital gains tax for an investor, you must ensure that the following steps have been taken:

2.3 Allocation

This section contains the following topics:

2.3.1 Process of Allocation

When the allocation process in the system is executed, it follows a sequence of events as described below, for each transaction:

  1. Identifying the applicability of any loads associated with the fund and transaction type
  2. Computing the basis for application of the loads
  3. Arriving at the load return values and load amounts
  4. Arriving at the number of units allotted for each transaction after applying the loads

2.3.2 Identifying Applicability of Loads

In the Fund Load Setup for any fund, any loads that are deemed to be applicable for a transaction are associated with the fund.

Some of the associated loads may be criteria-based loads, which would be applicable only if the criteria are satisfied.

Any such associated loads, for which the criteria of applicability is satisfied, and that are defined as to be processed at the time of allocation are identified by the allocation process at this stage, for the fund the transaction type and the transaction reference type as of the transaction date.

Overridden loads

If any of the applicable loads has been overridden after the transaction was authorized, (through the Transaction Load Override facility) the overridden values are picked up.

2.3.3 Computing Basis for Applying Loads

After obtaining the loads that must be applied, the process then computes the basis upon which the load return value may be arrived at. The basis could be an amount, number of units or a number of days. The actual return value of the loads, as applicable, will be computed on this basis value.

In arriving at the basis values, the process makes the following validations:

Letter of Intent transactions

If the transaction is designated as a Letter of Intent transaction for the investor, the basis computation is as follows:

Basis Amount = LOI Amount

Basis Units = Basis Amount / Transaction Base Price for the transaction type on transaction date.

This validation is made only for IPO, subscription and switch-in transactions where the nature of the investment is “in”.

Rights of Accumulation load

If the load is cumulative, and the investor is an ROA (Rights of Accumulation) investor, the basis amount is computed according to the option chosen by the AMC for interpretation of the history of investment of the ROA investor. The total holdings of the investor in the fund or load group are considered to arrive at the basis amount. If the ROA load is designated as applied at a CIF level, then the total holdings of all investors of the CIF, in the fund or load group are considered.

Basis Units = Basis Amount / Transaction Base Price for the transaction type on transaction date.

Basis Definition Loads

If the load is a basis load as defined in the Basis Definition screen, then the basis values (i.e., the basis units or basis days) are taken from the definition made in that screen for the load. In such a case,

Basis Amount = Basis Units * Transaction Base Price for the transaction type on the transaction date.

Ageing Loads

If the load is period-based (i.e., ageing) load,

Basis Amount = Transaction Amount

Basis Units = Basis Amount / Transaction Base Price for the transaction type on transaction date.

This validation is made only for redemption and switch-out transactions, which are “out” transactions.

Gross-based transactions for which the load slab definition is on a net basis

For gross transactions, where the load slabs applicable are defined on a net basis, the process recalculates the basis amount to reflect the same.

Normal loads

If all the above conditions are not present, then the load is a normal load, and the basis is computed as follows:

Basis Amount = Transaction Amount

Basis Units = Basis Amount / Transaction Base Price for the transaction type on transaction date.

After the Basis Amount and Basis Units are known, the process then proceeds to identify the loading slab and compute the actual applicable return value.

2.3.4 Arriving at Load Return Value and Load Amounts

Arriving at the return value

Using the Basis Amount and the Basis Units, the actual applicable return values and load amounts are calculated by the allocation process.

The return value is calculated using the load calculation method defined for the load. This could be Slab Basis, Weighted Average or Linear Interpolation.

For ageing loads, the return value is arrived at by considering the link transaction that is being aged.

While arriving at the return value, the allocation process also validates for the following:

The actual return value could be either a percentage figure or an amount.

Price-add In for LTP (loaded to price) loads

If the installation has a “price add-in” definition, the return value for loaded to price loads is interpreted further using the expression

Return Value = b / {1 – b - bc} where b = return value (without the add-in factor), and c = the applicable VAT percentage, if any.

The return value that results from the above expression is used as the final return value.

Price-add in for NLTP (not loaded to price loads)

If the installation has a “price add-in” definition, the return value for loads independent of price is interpreted further using the expression

Return Value = b / {1 + b + bc} where b = return value (without the add-in factor), and c = the applicable VAT percentage, if any.

The return value that results from the above expression is used as the final return value.

Price Add-on for loads

If the installation has a “price add-on” definition, the return values arrived at after applying the load calculation method (either Slab Basis, Weighted Average or Linear Interpolation) need not be interpreted further, and are considered the final return values.

Arriving at the load amounts

After the final return values are computed as explained earlier, the load amounts are arrived at by applying the return values as follows:

For loads with the return value as a percentage:

For loads with the return value as an amount:

Capital Gains Tax as an allocation time load

If the Capital Gains Tax is defined as an allocation time load and is applicable for the transaction, it is applied on the price as follows:

The average cost of units held by the unit holder in the fund is calculated. If this is lower than the base price of the transaction (net of all other loads), the CGT is applied on the difference.

Load amounts for CDSC loads

In the case of Contingent Deferred Sales Charge loads, the loading is based on the order of computation defined for the fund in the General Operating Rules, of the following:

For reinvestment units, the load applied is always zero.

Loads are applied on units in the other two categories based on the order of processing defined for the fund.

CDSC Computation

FCIS allows you to compute the Contingent Deferred Sales Charge (CDSC) in one of three ways; LOCOM (Lower of Cost or Market Value), Market Price (Market appreciation method and Class B (CDSC Class B method), Redemption Value. You can define the CDSC computation method while designating the rules that will govern the operation of the fund in the General Operating Rules screen. In addition, you can also specify whether the holding period should be considered while calculating the age of investments during computation of Contingent Deferred Sales Charge.

If CDSC calculation method at Fund level is selected as LOCOM, Contingent Deferred Sales Charge is computed as follows:

L = Least of subscription, Reinvestment or Switch-In transaction Price and the Redemption Base Price

((Redemption Base Price – L) / Redemption Base Price) * Redemption Units

Redemption Units – Market Appreciated Units

Contingent Deferred Sales Charge is computed based on the Inheritance Fee Structure as follows:

If CDSC calculation method at Fund level is selected as Class B, Contingent Deferred Sales Charge is computed as follows:

For example, CDSC Fee Structure for Schroder Guaranteed Return Fund VIII (Class B) 006-120802-479 is as follows:

Dealing Days between the following Period

From

To

CSDC Rate

02-Nov-02

01-Nov-03

2.85%

02-Nov-03

01-Nov-04

2.25%

02-Nov-04

01-Nov-05

1.65%

2-Nov-05

01-Nov-06

1.05%

02-Nov-06

01-May-07

0.45%

Maturity

0%

Dealing Price = TRUNC (Redemption Base Price – (Price for Investment in IPO/Subscription Period * CDSC Fee% derived from above Table), Rounding Precision for NAV from General Operating Rules)

The Round Of Truncate for this calculation will be always ‘Truncate’ and number of decimals will be equal to the number of decimals specified for NAV in the General Operating Rules screen. This Price will also be stored as Allocation Price.

CDSC Fees = ROUND ((NAV-Dealing Price)* No. Of Units Redeemed, No. Of Decimals from Fund Load)

The RoundOfTruncate for this Fund Load will be “R” and No. Of Decimals will be 2.

If CDSC calculation method at Fund level is selected as redemption value, then while computing Contingent Deferred Sales Charge the system will always consider the free shares first. Only once the free shares get exhausted the system will consider the other transactions on FIFO basis.

Rounding off the load amounts

For LTP load amounts, the rounding rules defined in the Fund Load Setup for the fund are applied, to arrive at the rounded-off load amount.

For NLTP load amounts, the currency rounding rules are applied to arrive at the rounded-off load amount.

The VAT amounts are also computed and rounded off as follows:

For LTP loads, VAT amount = Vat percentage * rounded-off load amount. The rounding rules defined in the Fund Load Setup for the fund are applied, to arrive at the rounded-off VAT amount

For NTLP loads, VAT amount = Vat percentage * rounded-off load amount. The currency rounding rules are applied, to arrive at the rounded-off VAT amount

The final load amount

The final load amount is arrived at by summing the rounded-off load amounts and the rounded-off VAT amounts.

Applying entry-time loads for outflow transactions

Typically, during allocation of outflow transactions such as redemption, switch out and transfer, when the loads are being computed, the system applies load values that are current at the time of the exit transaction. You can, however, configure the system to apply those load values that were prevalent at the time of initiation of the inflow transaction that is being aged. These are known as entry-time loads. If you have opted for entry-time loads, you would have indicated this in the Transaction Processing Rules for the fund.

For details, refer the chapter Setting Up Fund Rules II chapter of Fund Setup User Manual.

The example given below illustrates how entry-time loads are applied.

For example, your AMC floats the Citadel Growth Fund, effective from 1st January 2002 (the Rule Effective Date), with the following exit charges:

Days Slab

Return Value (Percentage)

1 – 30 days

3%

30 – 60 days

2%

60 – 90 days

1%

> 90 days

0%

Holdings in the fund are aged on a FIFO (first in, first out) basis.

With effect from 1st March 2002, you change the exit charges for the fund, as follows:

Days Slab

Return Value (Percentage)

1 – 30 days

2.5%

30 – 60 days

1.5%

60 – 90 days

0.5%

> 90 days

0%

Holdings in the fund continue to be aged on a FIFO (first in, first out) basis.

Mrs. Catherine Crenshaw, a unit holder in your AMC, subscribes into the Citadel Growth Fund through the following subscription transactions:

Mrs. Crenshaw redeems her investment in the Citadel fund to the tune of 1800 units, on 20th March 2002. Since holdings are aged on FIFO basis for the Citadel fund, 1000 units from subscription S1 and 800 units from subscription S2 would be validated for exit fee computation.

Taking the rule effective from 1st March 2002 into account, since it is the current rule, 0.5% exit fees will be applied on S1 and 2.5 % will be applied on the 800 units.

However, Mrs. Crenshaw requests that the exit fees that were prevalent on the date she subscribed into the fund, through S1 and S2, be applied. This would mean applying the exit fees applicable for the rule effective from 1st January 2002 to 1st March 2002. Therefore, 1% exit fees will be applied on S1 and 3% exit fees will be applied on the 800 units of S2.

Again, on 01st April 2002, Mrs. Crenshaw redeems another 2000 units. If she opts for entry-time loads, 1700 units of S2 will be redeemed with 2% exit fees and 2.5% of exit fees will be applied on the 300 units of S3, according to the rule effective between 1st January 2002 and 1st March 2002. If she does not opt for entry-time loads, 1.5% exit load will be applied on 1700 units of S2 and 2.5% exit load will be applied on 300 units of S3, in accordance with the rule effective from 1st March 2002.

If entry time loads are being applied as specified in the transaction processing rules for the fund, and the loads are overridden at the time of transaction entry, the overridden load values are applied.

Similarly, if entry time loads are being applied, and a unit holder deal has been specified for the unit holder, the deal values are applied.

Note

This feature is only available if your installation has specifically requested for it.

2.3.5 Computation of Allotted Units

After the final rounded-off load amounts have been arrived at, the allocation process computes the units to be allocated for the transaction.

It also calculates the final settlement amount for the transaction. This is total amount collected from the investor for “in” transactions such as IPO, subscription or switch-in, and is the total amount payable to the investor for “out” transactions, such as redemption and switch-out.

Unit’s computation

The process of calculation of the units to be allocated can be understood as shown below.

The computations for subscription and redemption transactions are shown. Switch transactions are treated as redeeming out of one fund and subscribing the redeemed amount into an other, so the processes of calculation are performed in two legs, the first, as a redemption, and the second, as a subscription.

Abbreviations used:

GT - Gross Transaction Amount

NT - Net Transaction Amount

UA - Units Applied / Units Allotted

SP - Subscription Base Price

RP - Redemption Base Price

TL - Total Load Amount

NX - Load Factor expressed in percentage and the load being an allocation time load not loaded to price, rounded off as defined in the Currency Maintenance.

LX - Load Factor expressed in percentage and the load being an allocation time load loaded to price, rounded off as defined in the Fund Load Setup for the fund

NLA - Flat amount not loaded to price (amount LTP loads), rounded off as defined in the Currency Maintenance.

LLA - Flat value loaded to price (amount NLTP loads), rounded off as defined in the Fund Load Setup for the fund

UP - Unit price

UC - Unit Cost

∑NLA = ∑Plus - ∑Minus

∑LLA = ∑Plus - ∑Minus

Description

Load with LTP = ‘Y’

Load with LTP = ‘N’

Both loads

Subscription BY AMOUNT (Gross)

Transaction accepted with Gross Amount

Price affected by the load factor.

Final transaction amount to be allocated is affected.

 

Computation logic

Gross amount

GT = Amount applied by the Investor

GT = Amount applied by the Investor

GT = Amount applied by the Investor

Not loaded to price loads

NLTP = 0

NLTP = ∑ (GT * NX ) + ∑ NLA

NLTP = ∑ (GT * NX ) + ∑ NLA

Loaded to price loads factor

LTP = ∑ (SP * LX ) + ∑LLA

LTP = 0

LTP = ∑ (SP * LX ) + ∑LLA

Unit price

UP = SP + LTP

UP = SP + LTP

UP = SP + LTP

Units allotted

UA = (GT - NLTP) / UP

UA = (GT - NLTP ) / UP

UA = (GT - NLTP) / UP

Total Loads

TL = NLTP + (LTP * UA)

TL = NLTP + (LTP * UA)

TL = NLTP + (LTP * UA)

Net Amount

NT = GT – TL

NT = GT – TL

NT = GT – TL

Unit cost

UC = GT / UA

UC = GT / UA

UC = GT / UA

Amount collected from Investor

Amount applied by the Investor and thus no additional amount needs to be collected

Amount applied by the Investor and thus no additional amount needs to be collected

Amount applied by the Investor and thus no additional amount needs to be collected

Subscription BY AMOUNT (Net)

Transaction accepted with Net Amount

Price not affected by load factor. Load amount calculated and to be collected from the investor sep­arately.

Transaction amount not affected by load factor. Load amount calculated and to be collected from the investors separately.

 

Computation logic

Net Amount

NT = Amount applied by the Investor

NT = Amount applied by the Investor

NT = Amount applied by the Investor

Not loaded to price loads

NLTP = 0

NLTP = ∑ (NT * NX) + ∑NLA

NLTP = ∑ (NT * NX) + ∑NLA

Loaded to price loads factor

LTP = ∑ (SP * LX) + ∑LLA

LTP = 0

LTP = ∑ (SP * LX) + ∑LLA

Unit price

UP = SP + LTP

UP = SP + LTP

UP = SP + LTP

Units allotted

UA = NT / SP

UA = NT / SP

UA = NT / SP

Total Loads

TL = NLTP + (LTP * UA)

TL = NLTP + (LTP * UA)

TL = NLTP + (LTP * UA)

Gross amount

GT = NT + TL

GT = NT + TL

GT = NT + TL

Unit Cost

UC = GT / UA

UC = GT / UA

UC = GT / UA

Amount collected from Investor

Total load amount to be collected over and above the amount applied by the Inves­tor

Total load amount to be collected over and above the amount applied by the Investor

Total load amount to be collected over and above the amount applied by the Investor

Subscription BY UNITS

Transaction accepted with units but load is on gross transac­tion amount

Price not affected by load factor. Load amount should be collected separately from the investor over and above the trans­action amount.

Transaction amount not affected by load factor. Load amount should be collected separately from the investor over and above the transaction amount.

 

Computation logic

Units allotted

UA = Units applied by the Investor

UA = Units applied by the Investor

UA = Units applied by the Investor

Net Amount

NT = UA * SP

NT = UA * SP

NT = UA * SP

Not loaded to price loads

NLTP = 0

NLTP = ∑ (NT * NX) + ∑NLA

NLTP = ∑ (NT * NX) + ∑NLA

Loaded to price loads factor

LTP = ∑ (SP * LX) + ∑LLA

LTP = 0

LTP = ∑ (SP * LX) + ∑LLA

Unit price

UP = SP + LTP

UP = SP + LTP

UP = SP + LTP

Total Loads

TL = NLTP + (LTP * UA)

TL = NLTP + (LTP * UA)

TL = NLTP + (LTP * UA)

Gross amount

GT = NT + TL

GT = NT + TL

GT = NT + TL

Unit Cost

UC = GT / UA

UC = GT / UA

UC = GT / UA

Amount collected from Investor

The Gross transac­tion amount to be col­lected from the Investor

The gross transaction amount to be collected from the Investor

The Gross transaction amount to be collected from the Investor

REDEMPTION BY AMOUNT (Gross)

Transaction accepted with Gross Amount

Price not affected by the load factor. Load amount to be deducted from the Redemption amount prior to payment for Redemption

The final transaction amount not affected by load factor. Load amount to be deducted from the redemption amount prior to payment for redemption

 

Computation logic

Gross amount

GT = Amount requested by the Investor

GT = Amount requested by the Investor

GT = Amount requested by the Investor

Not loaded to price loads

NLTP = 0

NLTP = ∑ (GT * NX ) + ∑ NLA

NLTP = ∑ (GT * NX) + ∑ NLA

Loaded to price loads factor

LTP = ∑ (RP * LX) + ∑LLA

LTP = 0

LTP = ∑ (RP * LX) + ∑LLA

Unit price

UP = RP + LTP

UP = RP + LTP

UP = RP + LTP

Units allotted

UA = GT / RP

UA = GT / RP

UA = GT / RP

Total Loads

TL = NLTP + (LTP * UA)

TL = NLTP + (LTP * UA)

TL = NLTP + (LTP * UA)

Net Amount

NT = GT – TL

NT = GT – TL

NT = GT – TL

Unit Cost

UC = NT / UA

UC = NT / UA

UC = NT / UA

Amount payable to Investor

Net Amount

Net Amount

Net Amount

REDEMPTION BY AMOUNT (Net)

Transaction with Net Amount

Price affected by load factor. Allocation as existing in FC-IS now.

Transaction Amount affected by load factor. Allocation as existing in FC-IS now.

 

Computation logic

Net Amount

NT = Amount requested by the Investor

NT = Amount requested by the Investor

NT = Amount requested by the Investor

Not loaded to price loads

NLTP = 0

NLTP = ∑ (NT * NX ) + ∑ NLA

NLTP = ∑ (NT * NX) + ∑ NLA

Loaded to price loads factor

LTP = ∑ (RP * LX) + ∑LLA

LTP = 0

LTP = ∑ (RP * LX) + ∑LLA

Unit price

UP = RP + LTP

UP = RP + LTP

UP = RP + LTP

Units allotted

UA = (NT + NLTP) / UP

UA = (NT + NLTP) / UP

UA = (NT + NLTP) / UP

Total Loads

TL = NLTP + (LTP * UA)

TL = NLTP + (LTP * UA)

TL = NLTP + (LTP * UA)

Gross amount

GT = NT + TL

GT = NT + TL

GT = NT + TL

Unit Cost

UC = NT / UA

UC = NT / UA

UC = NT / UA

Amount payable to Investor

Net Amount

Net Amount

Net Amount

REDEMPTION BY UNITS (Gross)

Transaction accepted with Gross Amount

Price not affected by the load factor. Load amount to be deducted from the Redemption amount prior to payment for Redemption

The final transaction amount not affected by load factor. Load amount to be deducted from the redemption amount prior to payment

 

Computation logic

Units allotted

UA = Units applied by the Investor

UA = Units applied by the Investor

UA = Units applied by the Investor

Gross amount

GT = UA * RP

GT = UA * RP

 

Not loaded to price loads

NLTP = 0

NLTP = ∑ (GT * NX ) + ∑ NLA

NLTP = ∑ (GT * NX) + ∑ NLA

Loaded to price loads factor

LTP = ∑ (RP * LX) + ∑LLA

LTP = 0

LTP = ∑ (RP * LX) + ∑LLA

Unit price

UP = RP + LTP

UP = RP + LTP

UP = RP + LTP

Total Loads

TL = NLTP + LTP

TL = NLTP + LTP

TL = NLTP + LTP

Net Amount

NT = GT – TL

NT = GT - TL

NT = GT - TL

Amount payable to Investor

Net Amount

Net Amount

Net Amount

 

Price Basis Loads

Note

Any loads that have been defined as price basis loads are only used as the indicator for computing load values, and are not picked up during evaluation of criteria. That is, the oth­er load details specified for such loads, such as the return value, slabs and so on, are not taken into consideration. The difference between the Transaction Base Price and the Price Basis defined for the transaction is considered as an inherent fee or incentive, during allo­cation.

For instance, if the Price Basis for a transaction is ‘Offer Price’, and Transaction Base Price is 1.009 and the Offer Price is 1.060, the difference (1.06-1.009 = 0.051, without currency rounding) is considered as the inherent fee (since the TBP is less than the offer price). If the offer price were less than the TBP, the difference between the two is considered an inherent incentive.

2.4 Allocated Units for IPO Transactions

This section contains the following topics:

2.4.1 Overriding Allocated Units for IPO Transactions

In the Transaction Processing Rules for a fund, the maximum issue size applicable for IPO transactions in a fund is defined. This limit is a restriction on the total order value for IPO transactions. The IPO allocation process validates whether the maximum issue size limit is exceeded by the total order value.

When the total order value is below the maximum issue size, the number of units allocated for a transaction is the same as the number of units applied, that is, all orders will be fully allocated. When the total order value exceeds the maximum issue size, the orders are allocated based on the ratio of maximum issue size to total order value. In expression,

Quantity allotted = Quantity applied * (Maximum issue size / Total order value)

For such situations, the system provides an override, where you can specify the ‘allocable’ units as against the applied units. You can specify this override in the ‘FCIS IPO Units Override’ screen. You can invoke this screen by typing ‘UTDIPOUO’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

In this screen, when you select the ID and ISIN of the fund in respect of which you wish to provide an allocation override, the maximum issue size and the default allocable units, for each IPO transaction that is pending allocation in the fund, are displayed.

Fund ID

Alphanumeric; 6 Characters; Mandatory

Specify the fund ID. Alternatively, you can select fund ID from the option list. The list displays all valid fund ID maintained in the system.

ISIN No

Display

The system displays the ISIN number.

IPO Max. Issue Size

Display

The system displays the IPO maximum issue size based on the Fund ID selected.

Force Recalculation

Optional

Check this box to recalculate the IPO units.

Click ‘OK’ button. The system displays the following values:

Overridden Units

Numeric; 22 Characters; Optional

Specify the overridden units.

Override Or Not?

Optional

Select this check box, and specify the overridden units in the Overridden Units field.

In this screen, you can only override allocable units in respect of a transaction, when the maximum issue size limit is exceeded, subject to the following considerations:

The override that you specify in this screen must be authorized. The ‘authorize’ option must be selected in the Operation field, to authorize the overridden units.

When the original IPO transaction in respect of which units have been overridden is amended and a different transaction value has been specified, you can opt for re-computation of the allocable units, by checking the Force Recalculation box.

2.5 Unitizing Transactions during Book Closing Period

You can specify whether a transaction can be unitized, for a book closing date. The BlkClsOptional field present in the Client Country field, allows you to disable/enable the validation initiated during the allocation process, to verify whether the transaction occurs during the book closing period.

2.6 Unsettled Trades

This section contains the following topics:

2.6.1 Maintenance Activities

When you enter into a subscription transaction, FCIS allows you the option of redeeming the units that have been provisionally allocated to you by the system. Redemption transactions can be linked to unsettled inflow transactions as well as settled inflow transactions.

The maintenance you have to carry out is explained below:

Specify, for a fund, whether or not a redemption transaction can be linked to unsettled inflow transactions. This can be done in the ‘Policies’ section of the ‘Transaction Processing Rules’ screen where you may:

WARNING: Though, during amendment, you are allowed to change the status of the field ‘Link to Unsettled Inflows?’ from ‘Yes’ to ‘No’, this is NOT recommended. You may however change the status from ‘No’ to ‘Yes’.

 

Refer to the chapter Setting Up Fund Rules (II) in Fund Setup User Manual for further information on the Transaction Processing screen.

2.6.2 Process

You enter into a subscription transaction. The units are provisionally allotted to you. You would like to carry out a redemption transaction. The following is the workflow:

Case 1 – If payment is rejected

If payment is rejected, the following will happen:

Case 2 – If payment is accepted

If payment is accepted, all linked redemption transactions will be confirmed.

Note

For a pseudo switch Redemption, the unsettled subscription leg of transaction will have to be manually cleared or rejected.