Skip to main content

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:

  1. 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+

  2. 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.

  3. 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

rebate-contracts-profile.png

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

Rebate contracts can be run on-request from the UI from the Portfolios view or the Overview, against one or more portfolios.

On the Overview, right click the portfolio that you wish to calculate rebates for in the hierarchy on the right-hand side and select Fee calculation → Calculate rebates.

3399614467.png

Alternatively, you can reach the next step by going to the Portfolios view, searching for your portfolio(s) and selecting Fee calculation → Calculate rebates at the bottom of the screen.

3399417865.png

When running manually, the user first sees a screen which allows them to choose the date range for which to calculate rebates and set the Transaction/settlement date for the created transactions.

The start date and end date indicate the date range during from which we record the costs to base our rebates on. Please note, that in version 1.0 of the process, the rebates are always generated for the process run date, NOT the end date. In version 1.1, the user may choose the transaction date from this same UI; that transaction date is also used for the settlement date of the transactions.

After choosing "Confirm date selection", FA will start 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.

rebate_confirmation.png

This screen shows the results of the rebate calculation: each row corresponds with a transaction that will be created once the "Create rebates" -button is clicked. All rows are selected by default, but you can unselect the rows you don't want to be created. If you use filtering, non-visible selected items included also, so make sure you clear the filters before going forward.  The columns shown in the UI are:

  • Contract Portfolio: the contract that the transaction is related to

  • Recipient Portfolio: which portfolio to create the rebate transaction into

  • Source Portfolio: which portfolio contained the assets/costs that are the basis for the rebate

  • Security: the security that the costs are associated with, which we are getting rebates from

  • Rebate value: the value of the rebate, rounded to two decimals; this screen always shows up to two decimals, but if you happen to be working with a currency that has more decimals than that, this screen will show up to two decimals, but the transactions will be created with the correct amount of decimals.

  • Currency: the currency which will be used in the rebate tranaction

You can export the table to Excel by clicking the button 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. Checkbox selection does not apply to export.

Clicking on the "Create rebates" button creates the rebates shown on the screen and gives a simple notification once done.