7 Set up Loads
This topic explains about the process of setting up the different fees and incentives that would be applied by AMC.
Loads
- Types of Loads
- Parameters that form Basis for Applying Load
- Set up Loads in System
Types of Loads
When an investor transacts in an AMC, the AMC may charge the investor a certain fee for any or all of the transactions requested. On the other hand, the AMC may give the investor an incentive for reasons of continued loyalty, or for initial investment. These fees or incentives are identified as loads.
A load involves payment by one entity to another. Any entity that makes the payment is known as the From entity, and any entity that receives such payment is known as the To entity.
Accordingly, there are two basic types of loads, from which all other loads derive:
- Fees: Any payment for transaction charges that investors make to the AMC are fees.
- Incentives: An AMC sometimes makes a special preference in terms of charges for initial investors and for those investors that have transacted with the AMC over a considerable period of time. These preferences are known as incentives.
For instance, an AMC may stipulate that for the first 10 investors that invest in a newly floated fund, a differential favorable price would be applied. This is an incentive.
The recipient (or the To entity) of an incentive could be a unit holder, a broker or another entity.
A broker may also be required to pay a fee to the AMC for services rendered, such as commission processing and payment, reinvestment processing and so on. If the unit holder is not any of the involved parties then that load is a commission. (that is, the From or To entities are not unit holders).
Parameters that form Basis for Applying Load
Fees, incentives and commissions may be based on many different parameters, or combinations of these parameters, depending upon the requirements of the AMC.
While transacting, the AMC may attach loads to any transaction, be it a fee, incentive or a commission, which may be computed and applied on the basis of any of the following parameters:
Slab | From Date | To Date | Return Value |
---|---|---|---|
0-10000 | 15-10-2000 | 15-12-2000 | 5% |
Here the slab value may be reckoned as an amount or a number of units.
This means that for all transactions requested after 15-10-2000 and before 15-12-2000, for a volume that lies within the slab, the percentage of the load (incentive) applied is 5%. In such a case, for a transaction coming in on 15-10-2000, if the transaction amount is 5000 Rand, then the investor would be given an incentive amounting to an additional 250 Rand (5/100 * 5000) worth of units in the fund.
In the same case, if the load were a fee, then the investor would be given only 4750 Rand {5000 - (5/100 * 5000)} worth of units in the fund.
Generally, this is an early bird incentive in case of an IPO or subscription transaction period.
Load | Period | Return Value |
---|---|---|
L45 | 45 Days | 5% |
L4M | 4 Months | 4% |
L1Y | 1 Year | 3% |
Transaction Reference Number | Transaction Type | Transaction Amount | Transaction Date |
---|---|---|---|
T1 | Subscription | 1000 | 3-1-2001 |
T2 | Subscription | 2000 | 3-4-2001 |
T3 | Redemption | 3000 | 3-7-2001 |
Note:
The three loads in this example are to be reckoned as separate loads. A single load cannot have slabs based on all three parameters - days, months and years.Load applied based on the subscription transaction T1:
The number of days between the transaction T1 and T3 = Difference in days between 3-7- 2001 and 3-1-2001 = 180 days. This period falls in the slab for load L1Y, above, and the load applied will be 3% of the transaction amount:
Load = 3/100 * 3000 = 90
Load applied based on the subscription transaction T2:
The number of days between the transaction T2 and T3 = Difference in days between 3-7- 2001 and 3-4-2001 = 90 days. This period falls in the slab for load L4M, above, and the load applied will be 4% of the transaction amount:
Load = 4/100 * 3000 = 120
Note:
Both the loads applied as shown in the example above are based on periods, and also on the original subscription transaction(s) that have generated the units being redeemed, in a subsequent redemption transaction. These loads have no other basis than these two factors. Since they are based on the period for which the unit holder has continued with the fund, they are known as aging loads.Loading based on aging policy
In the example given above, the units value considered for the redemption transaction T3 could also be dependent on the aging policy designated for the fund. If the aging policy is designated to be FIFO (first-in, first-out), the aging would apply as follows:
Out of the 3000 units being redeemed, 1000 units would be aged to 180 days (as corresponding to the first subscription transaction T1).
Therefore, the load for the redemption of these 1000 units would be calculated as follows:
3/100 * 1000 = 30
The remaining 2000 units would be aged to 90 days (as corresponding to the first subscription transaction T2).
Therefore, the load for the redemption of these 2000 units would be calculated as follows:
4/100 * 2000 = 80
Therefore, the total loading for T3, with an ageing policy of FIFO, would be 30+80 = 110.
Loading based on Amount
For each amount slab, the AMC could charge a fee. This would be an amount-based load.
Loading based on Units
Similarly, as with amount-based loads, the AMC could charge a fee for each slab of units.
Loading based on Date and Amount
The fee charged could also be operable within a date range, and an amount range.
Loading based on Period and Amount
The fee could be charged on each amount slab based on a certain number of days, months or years that the unit holder remains in the fund.
Note:
If the lower boundary is to be inclusive, then a transaction value of 1000 currency units would be reckoned as falling in the slab 002 for any of the loads. If not, as in this case, then the transaction value of 1000 currency units would be reckoned as falling in the slab 001 for any of the loads.Transaction Reference Number | Transaction Type | Transaction Amount | Transaction Date |
---|---|---|---|
T1 | Subscription | 1000 | 3-1-2001 |
T2 | Subscription | 2000 | 3-4-2001 |
T3 | Redemption | 3000 | 3-7-2001 |
For the redemption transaction on 3-7-2001, the load based on period and amount is explained below, assuming that the ageing policy for the fund is designated to be FIFO (first-in, first-out). The load for this transaction is based on the period that has elapsed between the original subscription transaction and the redemption transaction through which the units resulting from the original transaction are redeemed. It also takes into account the amount being redeemed.
Load applied based on the subscription transaction T1:
The number of days between the transaction T1 and T3 = Difference in days between 3-7- 2001 and 3-1-2001 = 180 days. This period falls in the period slab for load L1Y, above, and the number of units falls in the units slab 001 for L1Y. The return value for the load applied will be 75 currency units.
Load applied based on the subscription transaction T2:
The number of days between the transaction T2 and T3 = Difference in days between 3-7- 2001 and 3-4-2001 = 90 days. This period falls in the period slab for load L4M, above, and the number of units falls in the units slab 002 for L1Y. The return value for the load applied will be 100 currency units.
Therefore, the total load amount applied for the redemption transaction T3 is 75+100 = 175 currency units.
Note:
Both the loads applied as shown in the example above are based on periods and amounts, and also on the original subscription transaction(s) that have generated the units being redeemed, in a subsequent redemption transaction. These loads have no other basis than these two factors. Consequently, they are known as aging loads.Date and Units: The fee charged could also be operable within a date range, and a units range.
Period and Units
Load | Period | Slab | From Units | To Units | Return Value | Lower Boundary Inclusive |
---|---|---|---|---|---|---|
L45 | 45 days | 001 | 0 | 1000 | 5% | No |
L45 | 45 days | 002 | 1000 | 2000 | 4% | No |
L4M | 4 months | 001 | 0 | 1000 | 4% | No |
L4M | 4 months | 002 | 1000 | 2000 | 3% | No |
L1Y | 1 year | 001 | 0 | 1000 | 3% | No |
L1Y | 1 year | 002 | 1000 | 2000 | 2% | No |
Transaction Reference Number | Transaction Type | Transaction Amount | Transaction Date |
---|---|---|---|
T1 | Subscription | 1000 | 3-1-2001 |
T2 | Subscription | 2000 | 3-4-2001 |
T3 | Redemption | 3000 | 3-7-2001 |
For the redemption transaction on 3-7-2001, the load based on period is explained below. The load for this transaction is based on the period that has elapsed between the original subscription transaction and the redemption transaction through which the units resulting from the original transaction are redeemed.
Load applied based on the subscription transaction T1:
The number of days between the transaction T1 and T3 = Difference in days between 3-7- 2001 and 3-1-2001 = 180 days.
This period falls in the slab for load L1Y, above, and the load applied will be 3% of the transaction amount:
Load = 3/100 * 3000 = 90
(Here again, if the aging policy is FIFO, only 1000 units would be aged, and the load would be 3/100 * 1000 = 30)
Load applied based on the subscription transaction T2:
The number of days between the transaction T2 and T3 = Difference in days between 3-7- 2001 and 3-4-2001 = 90 days.
This period falls in the slab for load L4M, above, and the load applied will be 4% of the transaction amount:
Load = 4/100 * 3000 = 120
(Here again, if the aging policy is FIFO, only 2000 units would be aged, and the load would be 4/100 * 2000 = 80)
Therefore, the total load amount applied for the redemption transaction T3 is 90+120 = 210.
If the aging policy is FIFO, the total load amount would be 30 + 80 = 110.
Note:
Both the loads applied as shown in the example above are based on periods, and also on the original subscription transaction(s) that have generated the units being redeemed, in a subsequent redemption transaction. These loads have no other basis than these two factors. Since they are based on the period for which the unit holder has continued with the fund, they are known as aging loads.Loading based on aging date
Ageing for period based loads is calculated based on the ageing date specified at the time of setting up a fund. It can be the dealing date, transaction date or the confirmation date. Period is calculated using the following formula:
Period = Transaction/Dealing date/Price date of the redemption Link transaction date of the corresponding subscription transaction.
Here, the link transaction date of the subscription is the date of inflow for the redemption.
Set up Loads in System
The Oracle FLEXCUBE Investor Servicing system provides the facility of setting up the pattern according to which you can process loads.
- Initiate the load in the system, with all its parameters, in the Load Maintenance (Detail) screen. You can access this screen from the Maintenance menu category of the Fund Manager component. At this time, you must also create any derived loads or basis loads, as applicable, for the load.
- Have another user authorize this load, in the Load Maintenance Find (Summary) screen. This screen may be accessed from the Maintenance menu category of the Fund Manager component. When a load is authorized, all the derived and basis loads (if any) that you have created for the load are also authorized simultaneously.
- At this point, you can edit any details for the load, including details of any derived or basis loads that you have created for the load.
- Map this load to be applied on transactions in the desired funds, in the Fund Load Setup screen. You can access this screen through the Fund Demographics screen, from the Fund Rules (Detail) option in the Maintenance menu category of the Fund Manager component.
- You can also map the load to be applicable for a group of funds defined as a load group. You can do this through the Group Load Mapping screen, accessing it through the Maintenance menu category of the Fund Manager component.
- Authorize the fund (with all its fund rules) in the Fund Rule Find (Summary) screen. You can access this screen from the Maintenance menu category of the Fund Manager component.
Note:
- After you create a load in the Load Maintenance screen, you can edit the details as many times as possible, as long as the load is not authorized. During editing, you can define any new derived loads or basis loads, or edit any previously created loads.
- After a load is authorized, you can edit the details, provided the load is not already mapped to a fund or a load group, through the Fund Load Setup or Group Load Mapping screens. If you do edit an authorized load under these constraints, your changes will be saved as unauthorized changes. These must be subsequently authorized to be reflected in the database.
- After a load is authorized and then subsequently mapped to a fund or a load group, you cannot edit any of the load details.
Refer topic Setting up Funds and Authorization, respectively, in this user manual for more information on the Fund Load Setup screen and the authorization of a fund.
- Process Load Maintenance Detail
This topic provides the systematic instructions to capture cut off time for each currency that is maintained in the system. - Load Maintenance Summary
This topic provides the systematic instructions to perform the basic operations on the selected records. - Process Across Schemas Load Mapping Detail
This topic provides the systematic instructions to map loads to different schemas. - Across Schemas Load Mapping Summary
This topic provides the systematic instructions to perform the basic operations on the selected records. - Process Exchange Rate Source Mapping Detail
This topic provides the systematic instructions to map the Exchange Rate Sources created across schemas. - Exchange Rate Source Mapping Summary
This topic provides the systematic instructions to perform the basic operations on the selected records. - Trailing Fees
This topic explains about Trailing Fees. - Process Payment Group Maintenance
This topic provides the systematic instructions to maintain payment groups. - Payment Group Maintenance Summary
This topic provides the systematic instructions to perform the basic operations on the selected records. - Process Periodic Load Maintenance Detail
This topic provides the systematic instructions to maintain periodic loads. - Periodic Load Maintenance Summary
This topic provides the systematic instructions to perform the basic operations on the selected records. - Computation of Trailing Fees
This topic explains about computation of trailing fees. - Methodologies of Trailer Commission Computation
This topic explains about maintenance required for various methods of computation for trailer commission. - Process Trailing Commission Accrual Processing
The accrual of trailer commission for a fund or group of funds can be executed as a job, which you can trigger in the Trailing Commission Accrual Processing screen. - Process Trailing Commission Payment Processing
The payment of accrued trailer commission for a fund or group of funds can be executed as a job, which you can trigger in the Trailing Commission Payment Processing screen. - Process Target Based Fee
This topic explains the systematic instructions to maintain target based brokerage at AMC-Fund-Broker level. - Target Based Fee Summary
This topic provides the systematic instructions to perform the basic operations on the selected records. - Process Entity Commission Sharing Detail
This topic provides the systematic instructions to set up the rules according to which trailer commissions could be shared. - Entity Commission Sharing Summary
This topic provides the systematic instructions to perform the basic operations on the selected records. - Process Campaign Maintenance
This topic provides the systematic instructions to maintain the campaign details. - Campaign Summary
This topic provides the systematic instructions to perform the basic operations on the selected records. - Process Campaign Group Maintenance
This topic provides the systematic instructions to group the selective campaign maintenance into one campaign group. - Campaign Group Summary
This topic provides the systematic instructions to perform the basic operations on the selected records. - Process Campaign Counter Updation
This topic provides the systematic instructions to update campaign counter for a particular transaction number. - Campaign Counter Updation Summary
This topic provides the systematic instructions to perform the basic operations on the selected records. - Process Admin Tax Maintenance Detail
This topic provides the systematic instructions to maintain the Admin Tax calculated. - Admin Tax Maintenance Summary
This topic provides the systematic instructions to perform the basic operations on the selected records.