Handle contract rebates (kickbacks)
Overview
Rebates, sometimes referred to as "kickbacks", refer to situations in which fees are paid for investments, but part of those fees are paid back. For example, we might get an agreed-upon percentage of management fees returned to us by the fund company whose funds we are investing in.
Rebate contracts may be simple or complex. An example of a simple rebate contract would be one where investors simply receive a flat percentage of their fees back. A more complex rebate contract might be one where investors receive rebates with various different rebate percentages, which vary depending on:
The security - some securities pay a bigger fraction of fees back as rebates
The size of our investment - investing more money may entitle one to larger rebate percentages
The type of cost applied - do we get rebates for management fees, performance fees, subscription and redemption fees, or all of the above?
Rebate structures may also be simple (investors directly receive rebates for their investments) or more complex (multi-tiered hierarchies).
The purpose of the rebate contracts extension is to make it easier to handle both simple or complex rebate calculations/structures. It supports simple setups, but also calculating variable rebates depending on the criteria mentioned above. It also supports multi-tiered hierarchies of contracts, intermediate parties and investors, with the ability to pay out rebates to various levels within this hierarchy. We may pay out rebates to the investors themselves, to the intermediate level (e.g. investors' sales representatives) or to the asset management/fund distributor company itself.
This extension may be used by fund managers who are receiving or paying out rebates, or by asset managers who are receiving rebates (and keeping them or paying them forward, as the case may be). In practice, the extension is a combination of a portfolio profile and a process which is run against portfolios
Rebate calculation logic
The basic formula is: change in ex-post cost type X of position Y for date Z * rebate percentage for cost type X of security Y for date Z
More simply: accrued daily cost * rebate % for that cost
This formula is applied for each underlying position and each day in the selected time period, and the results are aggregated into one or more rebate transactions.
Determining the rebate percentage
Rebate percentages are calculated per:
Contract
Day
Transaction type
Security
I.e. a specific rebate percentage is determined by the contract, day, transaction type, and security.
E.g. to calculate the rebate percentage for contract X's ongoing costs for security Y on 2020-09-18:
We look for percentages and their corresponding AUM thresholds from that contract for ongoing costs for security Y.
For example, let's say we find percentage 40% for threshold 0 - 10 000 and 60% for threshold 10 000+
We calculate the market value of the total position in security Y on that date (including the contract portfolio itself and all portfolios directly or indirectly under that contract)
For example, let's say the underlying portfolios contain 1000 units of the EUR-denominated security, and the market price of the security on 2020-09-18 is 15 EUR → total AUM for that security on 2020-09-18 is 15 000 EUR.
Note, that even if these 1000 units/15 000 EUR are split among multiple portfolios, the rebate percentages for each of the portfolios are still determined based on the total 1000 units/15 000 EUR.
We see which threshold(s) (found in step 1) the AUM falls into (calculated in step 2); how this part works depends on the calculation method selected in the rebate contract profile (see below).
Single percentage
In single percentage mode, we only use matching AUM thresholds and multiply them with corresponding costs
In this example, total position of security Y on 2020-09-18 is 15 000 EUR, which falls into the 10 000+ AUM threshold. This means we have a 60% rebate for all on-going costs in security Y on 2020-09-18.
E.g. if we have a 30% rebate for AUM 0-100 000 and 50% rebate for AUM 100 000+, an AUM of 200 000 will have a 50% rebate of the full 200 000 position, NOT 30% for the first 100 000 and 50% for the second 100 000!
Incremental percentages
In incremental percentages mode, we use a weighted average rebate percentage based on matching and smaller AUM thresholds. We multiply that weighted average rebate percentage with the corresponding costs
In this example, total position of security Y on 2020-09-18 is 15 000 EUR, which falls into the 10 000+ AUM threshold. This means we have a 40% rebate for 10 000 EUR of our 15 000 EUR investment, and 60% rebate for 5 000 EUR of the 15 000 EUR investment. This gives us a weighted average of 46,66...% rebates of on-going costs in security Y on 2020-09-18.
E.g. if we have a 30% rebate for AUM 0-100 000 and 50% rebate for AUM 100 000+, an AUM of 200 000 will have a 30% rebate for the first 100 000 and 50% for the second 100 000, averaging out at a 40% rebate for the full 200 000 EUR.
AUM groups
Sometimes we need to combine the assets of multiple different securities when determining the thresholds. For example, this may happen when an investor owns multiple funds from the same fund company, and the rebate model is determined by total ownership of that fund company's funds.
AUM Groups are defined in the bottom of the rebate contracts profile (please refer to "The rebate profile" -section below).
AUM Groups are not mandatory: securities that are not part of any group are calculated alone (i.e. the size of the position that specific security determines its thresholds).
Please note, that a single security should NOT be part of multiple AUM Groups, but the UI does not have validation to account for this.
AUM Groups may contain securities in different currencies. If this happens, the AUM of the group is converted (using each day's close FX rates) to the security currency that we are calculating rebates for. Please note, that this may slow down the calculation of rebates.
Example 1 - AUM group with a single currency
Setup:
Rebate contract that gives 0% rebates for investments from 0 - 100 000€, and 30% rebates of ongoing fees for investments from 100 000€+, with a single fee percent (not incremental percentages).
Securities "Asian Stars Equity Fund" and "Asia ex Japan Equity Fund" belong to the same security group.
Rebate portfolio contains total positions of 60 000 € Asian Stars Equity Fund and 90 000 € Asia ex Japan Equity Fund.
Outcome: because of the rebate group, the rebate portfolio receives 30% of ongoing fees in both "Asian Stars Equity Fund" and "Asia ex Japan Equity Fund", because the AUM of the AUM group is 150 000€, which exceeds the 100 000€ threshold defined above.
If the AUM group wasn't defined, both positions would fall under the 0 - 100 000€ threshold, and neither would receive any rebates.
If we used incremental percentages instead of a single percentage, we would receive (150 000€ - 100 000€) / 150 000€ * 30% = 10% rebates for ongoing fees for both positions.
Example 2 - AUM group with multiple currencies
Setup:
Rebate contract that gives 0% rebates for investments from 0 - 100 000€, and 30% rebates of ongoing fees for investments from 100 000€+, with a single fee percent (not incremental percentages), for Asian Stars Equity Fund.
Rebate contract that gives 0% rebates for investments from 0 - 500 000 SEK, and 30% rebates of ongoing fees for investments from 500 000 SEK+, with a single fee percent (not incremental percentages), for Hypothetical SEK-denominated Fund.
Securities "Asian Stars Equity Fund" and "Hypothetical SEK-denominated Fund" belong to the same security group.
Rebate portfolio contains total positions of 80 000 € Asian Stars Equity Fund and 400 000 SEK Asia ex Japan Equity Fund.
Outcome: when calculating the size of the rebate group of Asian Stars Equity Fund, we convert the Hypothetical SEK-denominated Fund position into EUR: 80 000€ + (400 000 SEK / 10 (SEK/€) ) = 120 000€ → Asian Stars Equity Fund receives 30% rebates.
When calculating the size of the rebate group of Hypothetical SEK-denominated Fund, we convert the Asian Stars Equity Fund position into SEK: 400 000 SEK + (80 000€ / 0,1 (€/SEK) ) = 1 200 000 SEK → Hypothetical SEK-denominated Fund receives 30% rebates.
If the AUM group wasn't defined, both positions would fall under their thresholds (0 - 100 000€ and 0 - 500 000 SEK), and neither would receive any rebates.
If we used incremental percentages instead of a single percentage, we would receive (120 000€ - 100 000€) / 120 000€ * 30% = 5%rebates for ongoing fees for Asian Stars Equity Fund, and (1 200 000 SEK - 500 000 SEK) / 1 200 000 SEK * 30% = 17,5% rebates for Hypothetical SEK-denominated Fund.
Please note, that the AUM threshold calculation (including AUM groups) is done separately for every day in the given time period.
Creating rebate transactions
A separate rebate transaction is created per:
Rebate source portfolio (portfolio containing the assets which result in rebates)
Transaction type
Security
If you would like to have separate rebates for each day, that would be achieved by running rebate contracts every day for a single day. Similarly, if weekly rebate transactions are required, the solution is to run the process once per week, etc.
Rebate transaction properties
Transaction & settlement date - selectable date, defaults to run date of the extension (for automated runs)
Amount (units)and trade amount (security currency) - the amount of the rebate; the trade amount is rounded to two decimals, and amount is rounded to however many decimals the security allows.
Unit price - 1 if possible without changing the trade amount based on amount rounding. Otherwise (if security has a higher block size) we use whatever unit price gives us the correct trade amount given the rounded amount.
Fx rates - AUTO (based on close prices)
Security - the security of the position that is the bases for the rebate
Transaction type - selectable in rebate contract profile
Parent portfolio - depends on the rebate recipient choice in the rebate contract profile (see below)
Status
Account
Int info - What rebate contract (portfolio shortName), rebate source (portfolio containing the assets, shortName), and dates the rebate is based on
E.g. rebateContract=51309153127;rebateSource="51309153127";startDate=2020-11-20;endDate=2020-11-27;
The rebate profile
 |
1. Rebate recipient
The rebate recipient determines which portfolio receives the rebate transactions generated from this rebate contract. The options and their consequences are:
Contract portfolio - All rebates are generated into the contract portfolio itself.
Direct sub-portfolios - All rebates are distributed into first-level child portfolios of the contract portfolio in such a way that each child receives rebates based on positions in their underlying portfolios.
Note, that this option assumes that children of the parent portfolio do not have overlapping descendant portfolios!
Note, that rebates generated based on assets in the contract portfolio itself are placed in the contract portfolio, and similarly rebates generated based on assets in a direct child portfolio are placed into that direct child portfolio itself.
Final sub-portfolios
Whatever portfolio contains the asset itself receives the corresponding rebate.
These choices correspond roughly with these use cases:
Contract portfolio
If e.g. an asset management company wants to calculate rebates which it keeps for itself
If contracts are defined separately for each portfolio containing assets, then this option may be used
If investors have parent-sub-portfolio structures and we want to aggregate rebates to the parent portfolio, this choice should be used
Direct sub-portfolios - If we want to distribute rebates to e.g. subsidiaries or individual client managers/salespeople depending on who "owns" a given client.
Final sub-portfolios
If investors have parent-sub-portfolio structures which share a single rebate contract, and want rebates to be generated into whatever (sub)portfolio contains the assets
If multiple portfolios share the same rebate contract (and their security-specific AUMs are pooled), but we want to distribute the rebates back to the underlying investor portfolios
Q: If I want to distribute rebates back to investors, should I define separate rebate contracts per investor portfolio, or a high-level one with Rebate recipient "Final sub-portfolios"? A: The difference between these two scenarios is, that a high-level rebate contract pools all underlying portfolios' security-specific AUMs together when determining which AUM threshold to apply; whether or not you want these AUMs to be pooled should determine which approach you choose. |
2. Previous rebate date
This field indicates the last date for which rebates have been generated. It may be used to determine which date range to generate rebates for when running rebates manually (with UI), and is always used when running rebate contracts in an automated way. When we generate rebates "since the previous rebate date", our date range starts from the date following the previous rebate date, up until the selected end date (which is the process run date, in case of automated runs).
This field is automatically adjusted by the rebate contracts process whenever rebates are generated. This means the process may be run with any frequency against "previous rebate date", and it will generate rebates exactly once for each day: no double-counting and no missed days will occur. The only risk of missed costs is, if costs for some date are adjusted after that day's rebates have already been generated. It is therefore advisable to run the extension after all the day's transactions have already been recorded.
3. Transaction type
This field determines the type of the rebate transaction which we will generate.
4. Rebate source
This field determines which security cost type we are using as the basis for rebate generation.
5. Calculation method
This selector provides two options to control how the AUM thresholds are used: Single percentage and Incremental percentages
6. Account tag
This selection is optional. Account tag to identify the accounts used to generate rebate transactions. If you don’t have any accounts with the specified tag, the default account is used. If you have multiple accounts with the same tag, the account is randomly picked from those with the tag.
7. Contract start and end dates
These selections are optional. They provide a way to specify a time period within which the contract is valid. The rebates are only calculated for the specified time period at the maximum.
For example, if the contract start date is 2022-06-01 and end date is 2022-08-31, and the rebates are calculated for the time period 2022-01-01 → 2022-08-31, the rebates will be calculated only for the time period 2022-06-01 → 2022-08-31.
If either of the fields is left empty, they don't have an effect on the calculation period.
8. Security selection
This area defines which securities the given selections (3 and 4 within the same "box") should be applied to.
9. AUM thresholds
This area determines the AUM thresholds which should be applied to the security selections in field 5 (given selections 3 and 4 within the same "box").
AUM thresholds are defined in security currency.
AUM thresholds are security-specific (please refer to the "How does the calculation work"-section)
The maximum AUM field is exclusive, whereas the minimum AUM field is inclusive. This means a value of 10 000 would not match a range of 0 - 10 000, but would match a range of 10 000 - 100 000
If the minimum AUM field is left empty, then any value under the maximum AUM value is within that threshold
If the maximum AUM is left empty, then any value over the minimum AUM value is within that threshold
If both the minimum and maximum AUM fields are left empty, any AUM levels match that threshold
If multiple AUM thresholds are met at the same time (taking inclusiveness/exclusiveness into account), they are all applied.
10. Type/source groups
Any number of "boxes" starting, with selections 3 and 4, may be added by clicking this button.
AUM groups
The AUM groups section was can be found at the bottom of the rebate contract profile. For an explanation of how AUM groups impact rebate calculation, please refer to the "AUM groups" -section under "Rebate calculation logic" above.
AUM groups are defined as any number of rows of securities. Each row is a separate AUM group, and securities whose AUMs should be combined when determining thresholds should be entered into the row.
Any number of AUM groups may be added with the "Add AUM group" -button.
AUM groups are deleted individually by clicking on the trashcan icon directly to the left of the group in question.
Usage instructions
On-request runs
You can run rebate contracts on request against one or more portfolios from the Portfolios view or the Overview:
In the Overview, right click the portfolio to calculate rebates for and select Fee calculation → Calculate rebates.
In the Portfolios view, search for the portfolios to calculate rebates for, select them, and click Fee calculation → Calculate rebates at the bottom of the screen.
Run the rebate calculation:
Choose from the following options:
Create rebates since previous rebate - FA keeps track of the rebates that have been calculated.
Manually fill in the start and end date of the rebate calculation period and define the transaction/settlement date for the rebate transactions.
Click Calculate to start the rebate calculation. You can also run the calculation in the background by clicking Calculate (background). If you choose this option, open the Confirm rebates task in the Tasks view, My tasks list to continue the procedure.
FA then starts the potentially heavy calculation of determining what rebates to create for the selected time period. This does not yet create anything or modify any data in the system. The amount of processing/time required should roughly correspond to running analytics on a portfolio group containing all the portfolios covered by the rebate contracts, against the selected time period.
 |
The Confirm rebates window shows the results of the rebate calculation. Each row corresponds to a transaction that will be created. You can uncheck transactions you do not want to save. Non-visible selected items are included also, so clear any filters before proceeding. The columns shown are:
Contract portfolio: The contract the transaction is related to.
Recipient portfolio: The portfolio where the rebate transaction is created.
Source portfolio: The portfolio that contains the assets/costs used as the rebate basis.
Security: The security the costs are associated with.
Rebate value: The value of the rebate, rounded to two decimals. This screen always shows the value up to two decimals, but if you work with a currency with more decimals, the transactions are created with the correct amount of decimals.
Currency: The currency to use in the rebate transaction.
You can export the table as an XLSX file by clicking Export table to Excel. You can use column filters to view only items you want to export, and all items visible in the table are exported. The checkbox selection does not apply to export.
Clicking on Create rebates creates the rebates shown on the screen and produces a notification once done.