About ISLA
Regulation & Policy
Legal Services
Our Events
News & Insights
Status: Best Practice Finalised, Last Updated: 28/09/2021
Question:
When there is a reference rate changes (e.g. EONIA switch), how should the change be reported on outstanding SFTs?
Best Practice:
In an example such as the EONIA rate switch, which is not currently covered by an industry protocol, if the rate change is not covered by parties confirmation it is recommended parties agree with each other upfront and in writing on the ways to process the rate reference change.
Outstanding trades reported under SFTR should be amended as follows:
1. Send a MODI report amending Field 2.59 (Floating Rebate Rate) of the current trade on the effective date of the new rate, keeping the same UTI.
2. Otherwise, if both parties mutually agree up front on the termination of the existing trade indexed on the legacy rate, followed by reporting a new trade with a new UTI indexed with the new reference rate. This option would translate into an ETRM action type on the legacy trade followed by a NEWT action type with a new UTI and a new reference rate (fields rebate rate & spread).
This agreement is explicitly agreed / 'recorded' up front with the counterparty ahead of the events.
In the case of other alternative rates not covered by ISDA protocol or a confirmation, parties should send an action type MODI on existing trades in order to keep the same UTI, unless there is a bilateral agreement between parties to do otherwise.
All new rates should be reported using the assigned 4-letter code assigned to the new rate within the ISO20022 standard, to the extent that a code is available. For example, €STR should be reported with "ESTR". Full list of specified codes can be found here. (SFTR-444)
Status: Best Practice Finalised, Last Updated: 28/09/2021
Question:
In cases where an Asset Manager is acting as an agent in a securities lending transaction, how should the LEI of the Asset Manager be reported given there is no specific field for reporting?
Best Practice:
In correspondence via ESMA's Q&A portal, ISLA raised this question and received the following response from ESMA.
'Whenever an investment manager acts as an agent lender, it should be identified in the field "Agent lender" with its LEI. In case the investment manger uses an entity to perform or undertake the agent lending activity, then that entity should be identified in the agent lender field. The identification of an entity should take into account the agreement between the entities.' (SFTR-443)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
How should Securities Lending swaps be reported when using tokenised principal baskets and collateral baskets? Specifically, where the underlying assets of the principal basket are not known before T+1.
Best Practice:
In some cases, the underlying securities in the collateral baskets of the principal are not known until after T+1, usually on settlement of the swap. Therefore, these trades cannot be reported at an ISIN level until the reporting deadline.
This occurs in a minority of cases, and the majority of swaps will be reported on T+1, for example:
Trade date = 2020-06-08
Opening date swap = 2020-06-11
First allocations of underlying ISINs of the baskets (Principal & Collateral) will be done as per current TPA logic, i.e. on 2020-06-11.
Therefore, reporting only possible on 2020-06-11 at end-of-day.
Where the underlying assets are not known until the settlement date, these trades should be reported on the opening date of the swap. (SFTR-349)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
When marking-to-market (revaluing outstanding loans to the close-of-business), should firms submit both a MODI report to update Field 2.56 (Loan Value) and VALU report to update Field 2.57 (Market Value) or just the VALU?
Best Practice:
Both the MODI and the VALU templates need to be generated for these events.
For MODI this means both fields 2.56 (Loan Value) and 2.57 (Market Value).
For VALU this is field 2.57 (Market Value) only. (SFTR-346)
Status: Best Practice Finalised, Last Updated: 10/08/2021
Question:
In relation to actual or contractual settlement date, what is the best practice for reporting return legs of SLEB transactions?
Best Practice:
Within SLEB, there are currently two methods of reporting returns that have been built into SFTR reporting systems. ISLA no longer recommends that all firms adhere to the ISLA developed best practice for reporting returns, as regulators have made clear they do not intend to change their guidance.
The ESMA position for reporting returns, as stated within their guidelines document, is as follows.
Partial Returns: Should be reported on a contractual basis (i.e. contractual settlement date + 1) ignoring settlement failure in the market. These should be reported with a MODI (reducing quantity). When the final value is returned fully, this should not be reflected by a MODI reducing the quantity to '0'.
Future dated full Returns: Should be reported on a contractual basis (i.e. date of agreement + 1) If on the day following the contractual maturity date the trade has not settled, a MODI report should be sent moving the maturity date to the following day or the day on which it is expected to settle until the return settles.
Due to the current XML schema and validation rules, for open term trades this is reported by sending a MODI to add a 'Maturity date', modify the trade to fixed term (2.21 Open Term changed from TRUE to FALSE, 2.22 Termination Optionality changed to 'NOAP').
Same day full returns: Should be reported on an actual basis (i.e. actual settlement date + 1) by sending an ETRM.
The contractual reporting element of the guidance that ESMA has provided, is not operationally possible to enact within agency lending programmes, for legal purposes. Therefore, most agent lenders as well as other participants, opt to report returns using best practice developed by ISLA. ISLA suggested this market practice to ESMA as part of the original consultation, and subsequent Q&A processes for SFTR, however this approach was not adopted.
ESMA's guidance to report returns in this way, was not released until January 2020. Vendors and many proprietary system owners had already built to the ISLA developed model and agreed that it was too late to adjust prior to Phase 1 go-live. The majority of firms continue to use the ISLA developed model, due to the significant build cost and potential for guidance changes as part of the upcoming review of SFTR due in January 2022.
The ISLA developed best practice for reporting returns, which was formulated by the ISLA SFTR Working Group, as follows.
All returns reported on an actual-settlement basis and not contractual, with no requirement for advising failed status reporting.
Partial returns: should be reported with a MODI (reducing quantity). When the final value is fully returned, this should not be reflected by a MODI reducing the quantity to '0'.
Open term full returns: should be reported with an ETRM on an actual basis.
Fixed term full returns: should not be reported will not be reported (Once the maturity date has passed, the trade is marked as matured at a TR level and closed). Settlement failure for full return of fixed-term will report a MODI, extending the maturity date, repeated until settlement.
Currently, the expectation is that the SFTR legislative review is due to take place in January 2022. (SFTR-337)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
How are intragroup transactions reported?
Best Practice:
There are no exemptions in relation to reporting of intragroup SFTs by counterparties subject to the reporting obligation. Therefore, when an intragroup SFT is concluded, the counterparties should report it in accordance with Article 4 of SFTR.
The collateral taker must also report any collateral re-use where the collateral is posted to another legal entity within the group. (SFTR-296)
Status: Communications Review, Last Updated: 20/02/2024
Question:
How should reverse stock loans be reported?
Best Practice:
Companies should book the trades to the template that best fits (REPO) and annotate the trade agreement in Field 2.09 (Master Agreement Type) under which it is governed.
Else these trade types do not fit into the SLEB template, as this only facilitates the loan of securities.
See ESMA Guidelines on Reporting under Articles 4 and 12 SFTR - Section 4.2.5, point 36, pg.12:
Cash-driven SLBs, also known as "reverse securities loans", have to be reported as a repo. Where a cash-driven SLB is reported using the repo fields, it should be noted that the Master agreement type should reflect the relevant underlying agreement (e.g. GMSLA).
Reporting agents should note that the scope of SLB reporting in the MMSR Reporting Instructions version 3.6 has been significantly reduced in comparison to version 3.5. Following a consultation with reporting agents, it was concluded that restricting the reporting of SLBs against cash to reverse stock loans / reverse securities loans achieved the right balance in view of the reporting burden and the information required. The new reduced scope of SLBs against cash also provides alignment with the Securities Financing Transactions Regulation (SFTR), in that the guidance for SFTR considers reverse securities loans as fundamentally equivalent to a repo and requests that these types of SLBs be reported as a repurchase agreement rather than as a securities loan (see, for instance, Section 4.2.5 of ESMA Guidelines on Reporting under Articles 4 and 12 SFTR of 29/03/2021).
22 Regulation (EU) 2015/2365 of the European Parliament and of the Council of 25 November 2015 on transparency of securities financing transactions and of reuse and amending Regulation (EU) No 648/2012 (OJ L 337, 23.12.2015, p. 1–34).
23 On occasion these structured trades may be referred to as ‘fixed cash pool’ transactions, to refer to the fact that the associated cash collateral is fixed instead of being varied to maintain margin like in ordinary ‘cash pool’
Additional Insight into Best Practice reporting approach
Why the Repo template is required over the SLEB template
It is not possible to report a reverse securities loan under SFTR using the loan and collateral data fields dedicated to securities lending by the RTS and ITS on-transaction reporting and the Validation Rules.
One obstacle to reporting reverse securities loans as securities loans arises from the fact that the SFTR reporting framework implicitly assumes, in the case of a transaction reported as a securities loan (Table 2, field 4, Type of SFT = SLEB), that any cash is identified as collateral while any security is identified as a loaned security.
The problem here is that the framework allows only one loaned security to be reported per transaction (Table 2, field 41, Security Identifier), whereas reverse securities loans typically involve multiple security issues.
It would be incorrect to try to resolve this problem by breaking up reverse securities loans into separate transactions each involving one security, which was one suggestion, as this approach would misrepresent the legal structure of the transaction and would also produce a set of apparently unrelated transactions.
Many of these could be terminated at different times, as they could be substituted, obscuring the true term of the exposure agreed by the parties. This approach would also be prohibitively complicated in view of the typical frequency and size of changes to the securities.
(SFTR-289)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
How should bonds borrowed transactions be reported where lender believes the fee-based borrow (in exchange for the asset lent) to be collateral received, yet the borrower believes it to be a fee-based loan?
Best Practice:
OTC bond vs bond (fee based borrow vs fee-based loan) SFTs, creates an issue where participants move one bond in exchange with another for the same value, free of payment (FOP).
Each trade will have its own UTI settling in the market and the borrower would always see the fee based borrow as the principle reportable transaction and the fee-based loan as the collateral on this transaction. This could be a many-to-one or one-to many.
There is risk on the client counterparty offset to this, that they could report the collateral borrow as the transaction; effectively creating a single-sided orphan at the TR.
It has been opined that on the assumption that as participants are trading under a GMSLA 2010 (or earlier) then, regardless of theirs or their counterpart's perspective on the loan/borrow aspect, there is no contractual provision to apply a fee to collateral received. Therefore, irrespective of how they 'see' the collateral on this bonds borrowed transaction, they have to decouple the SFTs and report them in their component parts. This is confirmed by disclosure that each will generate its own UTI.
Example:
1. Counterparty A lends 1mm UK Govt Bonds #1 to Counterparty B at 0.25% = UTI1234
2. Counterparty B lends 1mm UK Govt Bonds #2 to Counterparty A at 0.25% = UTI98765
Under the reporting requirements you are both required to bilaterally report each SFT which will match at the TRs and not create an orphan, for either transaction. You will report the SFTs as uncollateralised and not send a COLU entry for either.
Field 1.09 (Counterparty Side) defines your perspective for each SFT. In option 1 in the above example, Counterparty A will be "TAKE". In option 2 in the above example, Counterparty A will be "GIVE". Counterparty B will be the opposite on both accounts.
This sounds like an oxymoron, in the sense that you are forced to define taking collateral when in fact you are not, but this is all that is available under the current RTS.
Field 2.72 (Uncollateralised [SL] Flag) will be "TRUE" for both Counterparty A and Counterparty B in both options in the above example. (SFTR-280)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
Are government agency pension funds out-of-scope for reporting under SFTR?
Best Practice:
Beneficial owners (being in this case a government agency pension fund), located in the EU, have received a letter from their NCA that they are not in scope of the SFTR regulation. They previously had confirmation they were out of scope for EMIR regulatory reporting and this has now been provisionally extended to SFTR as well.
Previously having had confirmation they were out of scope for EMIR regulatory reporting, this has now been extended to SFTR as well.
These clients are government agency pension funds and, as such, ESMA determined they do not fit any of the financial or non-financial counterparty classifications in EMIR and SFTR, so are out-of-scope and do not need to report. This means single sided reporting will occur under SFTR in this instance.
See Level I Text 23rd December 2015
Article 2(a). Articles 4 and 15 do not apply to: Members of the European System of Central Banks (ESCB), other Member State bodies performing similar functions, and other union public bodies charged with, or intervening in, the management of the public debt. (SFTR-271)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
How should collateral swaps, liquidity swaps and other collateral transformation transactions be reported?
Best Practice:
See related Best Practice: SFTR-280 .
Collateral swaps and liquidity swaps should be reported. These and similar transactions such as collateral upgrade trades or bonds borrowed are forms of collateral transformation, whereby a holder of one type of security temporarily exchanges that security for another type.
A common motive for collateral transformation is to secure a High Quality Liquid Asset (HQLA) for the purpose of meeting the Liquidity Coverage Ratio (LCR).
Collateral transformation can be performed by either:
securities borrowing transaction, in which security X is given as collateral and security Y is received as a loaned security, or;
reverse repo of security A and a repo of security Y for the same purchase prices (but usually different repo rates) executed back to back.
Both of the above examples of a collateral liquidity swaps should be reported as two separate transactions, as they will have generated exclusive UTIs.
Collateral swaps, liquidity swaps, and similar collateral transformations should be reported as either back-to-back but unrelated, reverse repos, repos, or as securities lending transactions against non-cash collateral. (SFTR-270)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
For dividend arbitrage transactions: do lenders and borrowers expect to book these with a maturity date? If yes, and in a situation where the loan is moved to open, do lenders and borrowers expect to modify the loan (MODI) to open by removing the maturity date?
Furthermore, for fixed income borrowers; how are they going to handle UTI generation on pair offs/ Returns?
For example: If we have 100k shares on loan with a borrower and there is a partial return of 20k shares, we will book the partial return versus the 100k shares and reduce it to 80k shares (keeping the initial UTI). All borrowers will close the 100k shares and re-open 80k shares and therefore create a 20k return. In this example as the borrower is closing and re-opening the position.
Best Practice:
It has been unanimously agreed that where a maturity date field within participant's trading systems are commonly misused to create a flag or reminder to users, to address the commercials of a transaction, i.e. a div-arb trade, and therefore the date is not a contractual one, but one used for alternative purposes, the lending system should hold this notification date elsewhere.
Where transactions are paired-off then participants are advised to ensure that they can supress the default reporting template for the closing and opening legs and instead send a modification for partial returns. To do this successfully, they will need to append the UTI from the original loan position, to the rebooked one. (SFTR-265)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
Should Lombard Loans be reported under SFTR?
Best Practice:
See ESMA Final Report Reporting under Articles 4 and 12 SFTR: 06 January 2020
14(b). Lombard loans to undertakings, as described in the Guidelines, are in scope and should be reported as margin lending transactions. (SFTR-226)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
What is the impact on the reporting obligation of dumping markets. The issue has been raised for those markets where participants can unilaterally deliver assets into the custody of the counterparty and, in many cases, the counterparty is unaware for up to several days later.
Best Practice:
Back-office or operations desks generally monitor receipt of dumping market assets in omni accounts and allocate the SFT returns to specific transactions; else reject them if unknown. Upon allocation, the associated message template should be generated, i.e. an ETRM or MODI, depending on full or partial return (excluding full returns on fixed-term SFTs). (SFTR-213)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
When transacting with a non-EU trust bank, where beneficiaries of the underlying securities in SFTs are non-EU, is the obligation to provide the beneficiary's LEI or principal's LEI or is reporting required at all?
Best Practice:
Example scenario: "Within our securities lending program, one of our principal lenders is a trust bank with numerous beneficiary customers, including trusts and pension plans. When we enter into a SFTs with our borrowers for this trust bank, it is always in an agent capacity (as a non-EU agent lender) with the trust bank as principal. The underlying securities in the SFT are not beneficially owned by the trust bank, but rather by one or more of its beneficiaries. Those trust and pension plan customers are our global custody customers and they disclose their name and LEI in certain countries to comply with local regulations and tax rule."
Out-of-scope or third-party entities who trade with an in-scope entity have a responsibility to share certain information with their counterpart, if their counterparts are to remain compliant with ESMA for the reporting of SFTR.
That responsibility will be almost identical to the ALD process with 2 key differences:
Counterparties must be identified by LEI to report in Field 1.11 (Other Counterparty) and Field 1.13 (Beneficiary).
The shared information will need to be provided T+1 or sooner for loans and S+1 for collateral.
In this scenario the beneficial owners of the trust bank do not have to register or provide LEIs/or data to the Trust Bank, as they are out-of-scope participants. The Trust Bank does have to register and provide LEIs to the non-EU entity because, even though they too are out-of-scope, the end-borrower has a reporting obligation to reference this counterparty and therefore needs this mandatory information to remain compliant. (SFTR-196)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
In agency lending omni programs, is an allocation to a new fund reportable and what is the industry standard. Furthermore, what happens if the credit department of the borrower rejects a fund reallocation post settlement?
Best Practice:
SLB re-allocations are reportable under normal reporting lifecycle practices. If a borrower rejected an allocation for any reasons, e.g. a credit-ceiling breach, then the lender would need to be informed and reallocate to a new fund or recall the position; at this point normal lifecycle practices apply.
Example scenarios and subsequent report:
Allocation with a new UTI = NEWT.
Allocation with an existing UTI and the quantity has increased or decreased = MODI.
Allocation with an existing UTI and the quantity is zero and the term date is open = ETRM.
Allocation with an existing UTI and the quantity is zero and the return date is less than the fixed term date = ETRM.
Allocation with an existing UTI and the quantity is zero and the return date is greater than or equal to the fixed term date = do not report. (SFTR-179)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
Reported data that on submission fails validation and, due to missing data or otherwise, continues to NACK for further lifecycle events will need to be reported (replayed) to Trade Repositories to ensure full and correct records are received.
What procedure or practice should be considered regarding backloading?
Best Practice:
The recommendation, due to the technical implications of this question and members' concerns, is that no best practice can be provided. Firms with reporting obligations should consider the implications and related system developments required to align with regulatory text.
See Guidelines Reporting under Articles 4 and 12 SFTR 06 January 2020 ESMA70-151-2838
83. However, the TRs should review the "Event date" only to the extent that they verify that it is not a future date (this is captured explicitly in the validation rules) and:
A. in the case of "past" event dates (i.e. less than reporting date -1), these events do not alter the transactions after their maturity or termination, i.e. the reported event date is earlier than the maturity date and, if populated, the termination date (this is also reflected in the validation rules. TRs should also verify that the modifications sent with a past event date do not alter the previously reported maturity date. Furthermore, the TRs should not apply the reported change to the current Trade State Report (if the transaction is still outstanding) nor the past Trade State Report of the date for which the event was reported.
B. in the case of event dates equal to the reporting date or the day preceding the reporting date, the TR should apply changes to the Trade State Report based on the sequence of submissions.
88. In the case where multiple past submissions were rejected by a TR, the counterparty should correct and resend them as soon as possible and maintain the chronological order of the events. In the case where these previous reports concern events that occurred on the reporting date or day before and therefore would be considered by the TR for the purpose of providing Trade State Report (in line with the paragraph 83 above), the counterparty may also need to resubmit last report(s) to bring the record of the transaction to the most up-to-date state. (SFTR-178)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
Are pay-to-holds (PTH) reportable?
Best Practice:
Pay-to-holds are not transactions as defined by SFTR as there is no transfer of securities nor is there any credit extended. An SFT, by definition, is a transaction by which a counterparty transfers securities or commodities subject to a commercial commitment and that the borrower will return equivalent securities or commodities on a future date. (SFTR-177)
Status: Best Practice Finalised, Last Updated: 25/05/2021
Question:
How should a new evergreen SFTs be reported?
Best Practice:
Some parties book fixed-term evergreens as repos with a repurchase date at the end of the minimum notice period and, each business day, automatically move the repurchase date forward by one business day until it is terminated. If the parties have agreed that this is the legal form of the transaction, then such an evergreen repo should be reported as it is booked.
Distinguishing difference is where one party books with a term date and the other does not. It is recommended that an evergreen flag is used to identify such SFTs and to ensure that the term dates are populated consistently between counterparties.
An evergreen trade should be booked as per the terms of the trade that are agreed with the counterparty at the time of trade execution. This is often, but not always, detailed on a confirmation or term sheet.
There are 2 ways of booking an evergreen trade, as follows:
Method 1 - X Day Evergreen with Term Date
2.14 Maturity Date = DD/MM/YY
2.22 Termination Optionality = EGRN
Method 2 - X Day Evergreen without Term Date
2.14 Maturity Date = Null
2.22 Termination Optionality = EGRN (SFTR-175)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
How should pair-offs and other technical netting be reported?
Best Practice:
When offset borrowing/lending is being netted-off then they should be reported, as such they should be treated as individual component transactions; on the understanding there is no market settlement. Where net-offs are for back office operational purposes then they should not be reported.
If netting occurs, this is at a settlement level and would not impact the reporting of the underlying trades. (SFTR-172)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
Should fails curing (intraday securities borrowing) be reported?
Best Practice:
Intraday fails curing or borrowing are reportable SFTs, providing that the counterparts are within jurisdiction and therefore eligible.
ESMA Guidelines Reporting under Articles 4 and 12 SFTR: 06 January 2020
37. Fails-curing refers to the securities lending and borrowing arrangements of CSDs amongst their participants, aimed specifically at reducing settlement fails. A similar mechanism exists on the cash side, as intraday credit/overdraft to CSD participants.
39. ESMA confirms that such securities lending and borrowing arrangements fall under the definition of an SFT and as such are subject to SFTR reporting obligations.
ESMA Guidelines Reporting under Articles 4 and 12 SFTR: 06 January 2020
11. The following transactions should not fall under the definition of an SFT and should not be reported under SFTR:
a) Retail client lending governed by consumer credit legislation
b) Private banking loans and Lombard loans not related to securities financing
c) Syndicated lending and other corporate lending for commercial purposes
d) Overdraft facilities of custodians and CCP daylight lending facilities
e) Fails-curing intraday credit / overdraft
f) Central bank auto-collateralisation
g) Give-ups and take-ups in the execution and clearing chain
h) Commodities transactions entered into for operational and/or industrial purposes
i) Transactions involving emission allowances
The ICSDs that offer fails-curing facilities also offer voluntary delegated reporting services. (SFTR-170)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
How should the shaping of delivery obligations be reported under SFTR?
Best Practice:
Where a delivery obligation is shaped, parties should report a single SFT for the full obligation and not several SFTs (ie: one for each shape.)
Note that "shaping" here is a settlement procedure and does not refer to the allocation of block trades by agents. (SFTR-168)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
Should CCP-cleared SFTs be reported at a position or a transactional level?
Best Practice:
Investigations conclude that no CCPs are doing position reporting, as they cannot technically meet the requirements; because CCPs net after novating, whereas position-reporting requires netting prior to novation.
CCPs do not replace the individual contracts and UTIs with a new single contract and UTI. Hence, based on the above view by ICMA, members should not adopt the option of position-reporting for CCP cleared securities lending and repo SFTs.
When discussed, active participants confirmed that CCP SFTs should be reported at transaction (TCTN) and not at a position (PSTN) level.
Practitioners are advised to speak to their trade-flow service provider, therefore; Equilend, Pirum or Eurex (F7) for clarification. (SFTR-167)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Question:
In the event that a loan/borrow is called in, where two identical outstanding positions exist, how do counterparts guarantee that it is applied to the correct UTI and therefore avoid mismatching?
Best Practice:
There is a potentially small issue with returns, detailed in the following scenario:
There are two identical borrows/loans between the same counterparties, which are vs. the same commercial details but different UTIs.
When the borrower books a full or partial return, there is a risk that the return booking event will mismatch the UTI, i.e. both counterparts will potentially book returns in their systems to different SFTs; linking to different UTIs.
A possible solution would be for industry best practice to agree that in such situations, with multiple trade booking vs same ISIN/Same Fee/Rebate, the earliest trade booking should be returned first.
In the above scenario, recommended best practice is to clarify which UTI participants should book the return against, if unsure.
It is however recognised that this may be problematic for many firms to allocate the correct return to the relevant UTI, due to the additional development burdens of implementing SFTR. (SFTR-242)
Sorry! You need to be logged in to access this document.
This premium content is available to ISLA member firms only. If you do not have a login, please use the ‘Request Login’ within the Member login.
If your firm is not a member of ISLA, find out more information regarding our current members, the types of membership we offer, and the benefits of joining.
Find out moreContent access not allowed
This content is not allowed on this membership level.
Change your membershipContent access not allowed
This content is not allowed on this membership level.
Change your membershipAlready a member? Login to your account
Interested in becoming a member?
ISLA’s members span the breadth and depth of the securities lending industry, and there are many benefits of joining the Association’s network.
Become a member today
SFTR Best Practice 
