Depositaries are under a duty to ensure that cash flows into and out of an AIF, or through its manager (AIFM), are properly monitored and all payments made by or on behalf of investors for subscriptions of units or shares of an AIF are received and booked in appropriately designated cash accounts at a central bank, an EU-authorised bank or a non-EU authorised bank.

Against every portfolio we can upload the below data:

Each of these are stored in separate tables within Highwire v2. Once uploaded, we can run monitoring on all of this data. This procedure guide specifically outlines the process relevant to Cashflow file monitoring (summary diagram below).

There is a baseline for the data files that we request from clients for cashflow monitoring. This baseline ensures minimal manual input or manipulation of data when mapping to the respective data fields in Highwire v2.

It is common that data files will not meet all of the requirements below. We will review the files and propose solution to deal with any issue that present themselves.

Standard templates for these files can be found here.

The above files are provided by the client as part of the Cashflow Monitoring Wiki Request provided by the client at onboarding.

NAV files

The NAV files are needed as usually rules will be based on the cashflow as a % of NAV.

Usually we use the absolute %, so that the rule covers both positive and negative cashflows.

Client Cashflow files will have various details. How these get mapped into HighWire are set out in the document.

Cashflow Types and Cashflow Groups

One key aspect is that Funds-Axis will run automation scripts against the clients data files to create a “cashflow type.” These cashflow types then map into cashflow groups. As much as possible Rules and Reports should be based on Cashflow groups and, if needed Cashflow types.

The preferred (but not exclusive) cashflow types are as follows:

Data File Uploads

Cashflow and related data files will typically be sent by the client to our sFTP and from here they will auto-upload into HighWire.

Data Upload errors can be seen in Data Migration / Upload History.

Common error messages and how to resolve can be found.

After Cashflows have been uploaded, a range of calculations are performed based on the cashflow upload.

Calculations and Rules Processing all work off the Trade Date and hence the NAV also needs to be available for the Trade Date as detailed above.

Below is a summary of calculations performed:

Cashflow Rules

Cashflow Rules can then be constructed using the above cashflow groups. For example, the below.

Most rules are based on the cashflow as an absolute % of NAV. More granular rules are possible.

Results appear within the Cashflow Exception Management. Commentary can be added and exceptions closed.

The calculations processing is based off the Trade Date.

The rules processing is based off the Trade Date.

Accordingly, the NAV must also be available for the Trade Date.

Note: From a system perspective, trade date and settlement date are not mandatory. If they are not provided, they should be defaulted to be the date of the data upload. From an operations perspective, we should ensure that these dates are mapped in, particularly Trade date.

Note: We enable the upload of both Trade Date and the Settlement Date. Opening and closing balances are not treated as transactions and are therefore not subject to threshold monitoring.

Reporting

Reporting is available including in respect of:

• Cashflows
• Cashflow exceptions
• Cashflow Reconciliations (see below)

Cashflow Reconciliations

Cashflow Reconciliations to Opening and Closing Balance is also possible. This provides assurance that all cashflows have been uploaded.

It should be performed on a by-account and by-currency basis.

This requires Opening and closing balances to also be uploaded.

It needs to be maintained on a daily basis to avoid falling into disrepair.

Below is an example of the Highwire v2 fields and a description of the data to be mapped:

*When using/creating a unique ‘Cashflow transaction ID’ that contains duplicate ID line items, so long as these are against the same holding and transaction type these will be aggregated into 1 line.

Additionally, there can be duplicate transaction IDs so long as these relate to different funds.

**For opening/closing balance line items, in absence of a trade date/settlement date we can assume that this is the date of the cashflow file.

***In the absence of ISIN data within the cashflow file, Sedol can be used to complete this concatenation.

Upon review of the cashflow file it is common that, either in the absence of data or concatenation of multiple data fields, that the files require manipulation. Each file will go through an enrichment process of cashflow groups and normalise the cashflow types.

It is also possible to have the fields that require manual manipulation to be automated using the EasyMorph automation platform.

Note: To avoid potential upload failure, please ensure that there are no spaces at the end of data fields such as Portfolio Code. This includes the portfolios, manager and legal entity setup files and the cashflow monitoring file.