One-third of the reporting for AIFMD comes from static data, which is set up in the scheme master and does not change.
This is the following:
- AIF static data
- AIFM static data
- AIF share class
Please carry out the below checks, and then email your client the below email so that they can run the checks in parallel.
- Log on to environments
- Go to Governance Reports
- Run the below 3 reports and make sure they work. Check for blanks and anomalies.
This means:
- Checking the scheme master to ensure that ONLY those funds reporting (appearing on the list of funds provided by the client) have the AIFM set as their fund house β if any other funds have the AIFM as their fund house, their AUM will be included in the calculation of the AIFMβs AUM which is wrong. If there are any funds wrongly classified under the reporting AIFM then please raise a change request with the Projects team to amend where necessary.
- Checking that any funds that are no longer reporting funds (e.g. because they have closed) are set as inactive, AIF as FALSE, and no longer have the AIFM as their fund house structure β otherwise these will pull through for AIF report and be included in AIFM calculations.
- Checking all inactive schemes to ensure the AIFM is not the fund house structure for any of these.
- Running the AIF report for all funds of the AIFM, exporting to XML, and importing into Excel and checking there are no funds appearing which shouldnβt be there β and none missing. Do a 2-way VLOOKUP to the list of expecting fund to make sure.
- If there are any funds that require a nil return to be submitted, please ensure that these have been set up under a separate AIFM so to avoid any risk of them wrongly contributing to the AUM
- Please ensure that any Feeder funds are set up under a separate AIFM, so the prevent double counting with the Master fund.
Copy all, paste into new sheet and remove duplicates β then do your two-way lookup.
AIFM report:
Check that you have:
- AIFM as True for all reporting AIFMs
- AIFM reporting code populated β sense check to make sure it looks sensible e.g. a quarterly reporting manager should not have a code for an annual manager
- AIFM jurisdiction β for the majority this will be GB
- a reporting member state (for most clients this is GB)
- a 6 digit AIFM national code β check the length
- AIFM name β check this is appropriate
- AIFM EEA flag (True for most clients)
- No Reporting Flag is False unless last report
- LEI and BIC should be populated if you have these
- Old identifiers β optional and not appropriate for most β please flag where these come up
- No dummy data populating anywhere (e.g. dummy codes)
AIF static data report:
Check that you have:
- All reporting funds appearing
- Reporting member state is populated (GB for most clients)
- AIFM national code is populated (this is the FRN for the manager β all funds under the same manager should have the same number β 6 digits) β check the length
- AIF national code β 6 digits and unique for each fund β check the length
- AIF Reporting Content β this is the type of reporting. For most clients it is 24(1) and (2).
- AIF EEA Flag β True for most clients
- AIF Reporting Code β should be the same across all funds under the same manager. Check to make sure they look sensible (e.g. we are not reporting a fund as leveraged when it holds no derivatives and vice versa)
- Domicile of the AIF β for most clients this will be GB
- AIF No Reporting Flag β should be False unless this is the final return for the fund
- AIF identifiers – not mandatoryβ this is ISIN, LEI, BIC, sedol, CUSIP, Bloomberg, Reuters. Blank LEIs, ISINs, SEDOLs should be requested from the client. Everything else is not needed.
- AIF = True otherwise it wonβt pull through to AIF report
- AIF share class flag β should be true where more than one share class
- Master/feeder status β should be None unless master/feeder is in place, if master then should show master, and if feeder should show feeder
- First Funding Source Country β optional but for most clients will be GB. Second and third will not be populated for most clients.
- Predominant AIF type β will depend on the client. In most cases it will be Other or None. Should be sense checked e.g. a NURS fund should not have a predominant AIF type of Hedge Fund
- Typical deal/position size β optional, leave blank
- What is the frequency of investor redemptions β for most funds is daily β check the others with the client
- Standard defaults β maintain unless otherwise advised as follows:
– direct clearing flag β False
– What is the notice period required by investors for redemptions in days β 0
– What is the investor βlock-upβ period in days β 0
– Side Pocket percentage β 0
– Gates percentage β 0
– Dealing Suspension percentage β 0
– Other Arrangement Type β 0
– Other arrangement percentage β 0
– Investor preferential treatment Flag β False
– Disclosure Terms Preferential Treatment Flag β False
– Liquidity Terms Preferential Treatment Flag β False
– Fee Terms Preferential Treatment Flag β False
– Other Terms Preferential Treatment Flag – False
– AIF Total Arrangement Percentage – 0 - Special arrangements as a % of NAV β for most clients this is 0
- Stress tests β we use standard defaults unless the client wants to report something else:
– Stress Tests Results β liquidity – Stress tests on liquidity do not indicate an impending liquidity issue that is not already understood
– Stress Tests Results β Investments – Stress tests have not revealed any unexpected significant non-linear results
AIF share class report:
- Check all funds are appearing
- AIF = True
- AIF Share Class Flag = True where more than one share class
- Identifiers: optional but at least one must be populated – Share Class National Code (6 digits), Share Class ISIN Code (12 digits), Share Class SEDOL Code (7 digits), Share Class CUSIP Code, Share Class Bloomberg Code, Share Class Reuters Code, Share Class Name