Overview
FundApps uses several properties to accurately capture disclosure requirements for Securities Financing Transactions (SFT). Due to their complex nature, few general statements can be made regarding SFT assets. This article explains the properties used in FundApps to automate disclosure requirements for SFT.
I. Identifying SFTs by type
The asset property SFTType (Securities Financing Transaction Type) accounts for various kinds of transactions, such as lending, borrowing, repos, and reverse repos, while also allowing for general collateral taken and collateral given.
Available values (types of SFT):
Normal - standard position, held outright (not part of a SFT);
Lent - lent side of a securities lending transaction;
Borrowed - borrowed side of a securities lending transaction;
CollateralTaken - collateral taken from another counterparty as one of the legs of a repo, reverse repo, the collateral side of a lending/borrowing transaction or other collateral in SFTs;
CollateralGiven - collateral given to another counterparty as one of the legs of a repo, reverse repo, the collateral side of a lending/borrowing transaction, or other collateral in SFTs.
Using this basic framework, you would represent the following SFT examples as follows:
Type of transaction | SFTType for leg 1* | SFTType for leg 2 |
Lending | Lent | CollateralTaken |
Borrowing | Borrowed | CollateralGiven |
Repo | CollateralGiven (securities) | CollateralTaken (usually cash, can be securities) |
Reverse Repo | CollateralTaken (securities) | CollateralGiven (usually cash, can be securities) |
Other (e.g. margin loan) | CollateralGiven | CollateralTaken |
Every securities financing transaction has two legs, which can be expressed in the most simple form as collateral taken and collateral given (see ESMA’s SFTR consultation paper section 4.2.3 on this topic). In our initial data specification, both legs of repos and reverse repos would fall under either the collateral taken or the collateral given category.
We understand that it might be unconventional to think of the cash received in a repo as collateral taken, for example, but the concept of both legs of the transaction would still hold.
Note: the concept of one/two legs only applies to transactions such as repos and sell-buybacks. For more information, please see ESMA's memo here.
Another way to look at it is to consider the expected treatment to an existing Normal holding when SFT activity takes place.
Net position type per security logic for positions with existing normal long position:
Lent: Adjust long Normal holdings down by the lent quantity; create a separate record with the lent quantity.
Borrowed: Create a new, separate record with borrowed amount; Long Normal holding is unchanged
CollateralGiven: Adjust long Normal holdings down; create a separate record with the collateral given.
CollateralTaken: Create a new, separate record with collateral taken; Long Normal holding is unchanged
Repo: Adjust long Normal holdings down; create a separate record with the collateral given quantity
ReverseRepo: Create a new, separate record with collateral taken; long Normal holding is unchanged
To summarise these movements:
Adjustment to Normal positions is only made to Long holdings, and only for subtractive scenarios (lends and collateral given).
All other SFTType activity is added to the long, but in a separate holding record (i.e. new asset/ AssetId)
Short positions should always be SFTType=Normal
II. Additional asset properties
Properties | Description | SFTType | Jurisdictions |
HasTransferOfTitle | Boolean (TRUE or FALSE)
If set to TRUE, indicates that the legal title of the security is transferred in the SFT transaction, as determined by the relevant legal agreements. Setting this to FALSE indicates the collateral includes no transfer of title (that which is just a pledge/lien of assets would fall into this category).
Note: standard practice in securities lending agreements is that the title is transferred. | Lent
Borrowed
CollateralTaken
CollateralGiven | All |
HasTransferOfVotingPower | Boolean (TRUE or FALSE)
If set to TRUE, indicates if the power to exercise the voting rights of the assets is transferred in the SFT transaction, as determined by the relevant legal agreement. | Lent
Borrowed
CollateralTaken
CollateralGiven | All |
HasIntentionToExerciseVotingRights | Boolean (TRUE or FALSE)
Indicates whether a collateral taker has the intention to exercise the voting rights attached to the securities transferred, or not. | Borrowed
CollateralTaken
CollateralGiven* | Multiple (please refer to the Properties page in FundApps) |
AuthorisedLendingAgreement | Comma-separated list of values (country codes). Valid values: MY, PH, TH.
Accounts for various exemptions, i.e. if the stock borrowing and lending arrangements are covered under and comply with the special requirements provided by the regulators. See the rules from the Jurisdictions mentioned for details on each exemption before setting. | Lent
Borrowed
CollateralTaken
CollateralGiven | Multiple (please refer to the Properties page in FundApps) |
*When SFTType=CollateralGiven, HasIntentionToExerciseVotingRights only needs to be supplied when HasTransferOfVotingPower=true. HasIntentionToExerciseVotingRights then refers to the collateral taker.
It is assumed that a lender will always have a right to recall lent securities; therefore, there will be no property explicitly accounting for that.
III. Timing and sourcing the data
Since regulations require securities financing transactions to be identified along with normal portfolio positions, FundApps expects the data related to SFT to be delivered on a trade date (T) in the same way data for other positions is delivered. This will likely require coordination with your securities lending department/agent, prime broker, collateral management group, or others responsible for identifying this data on a daily basis.
IV. Positions file
Accounting for securities financing transactions in our rule package has an impact on the positions file you upload to FundApps. Please see this example of the input file, which shows a precise breakdown of how the position quantities should be supplied.
In the example, some quantity of the same asset is held outright (normally bought on the market), some of it is borrowed, and some has then been lent on further. The idea here is to represent the same security with different SFTTypes in separate lines, with different AssetIds. However, they share the same InstrumentId property. Please contact FundApps Support if you have any further questions regarding the revised positions file in FundApps.