SFTR Reporting Explained: Lifecycle, Fields, Fixes

Last updated: April 2026

The fastest way to understand why SFTR reporting is hard is to look at what happens when a single repo rolls overnight. The same trade generates a new report on day one, a valuation report on day two, a collateral update if the basket shifts, a margin update if the variation margin call moves, and a termination on the unwind. Both sides of the trade have to send their own version of every one of those messages to a trade repository within T+1, using the same Unique Transaction Identifier, the same ISO 20022 format, and values that match on dozens of fields. Miss any of that and the record lands in the breaks queue, where it sits until somebody calls the counterparty and asks whose timestamp is wrong.

That is SFTR in one paragraph. The regulation itself is Regulation (EU) 2015/2365, the “Securities Financing Transactions Regulation”, which went live in phases during 2020 and 2021. Its job is to make the repo, securities lending, buy-sell back and margin lending markets visible to ESMA and national regulators in something close to real time. The operational job it hands you is running a daily, dual-sided, reconciled transaction reporting pipeline for instruments that most front-office systems were never built to treat as reportable trades. This guide walks through what SFTR actually requires, who reports what, how the lifecycle works, where Luxembourg funds and banks get stuck, and the data quality problems that still eat reporting teams six years in.

Related reading: EMIR reporting explained

What SFTR actually covers

SFTR is narrower than it sounds. It does not cover every financing transaction a bank does. It covers four specific product types, defined in Article 3(11) of Regulation (EU) 2015/2365:

• Repurchase transactions (repo and reverse repo) under a master agreement like the GMRA.
• Securities or commodities lending and borrowing, typically under a GMSLA or equivalent.
• Buy-sell back and sell-buy back transactions, which look economically like repos but are documented as two separate outright trades.
• Margin lending transactions linked to the purchase, sale, carrying or trading of securities. This is the prime brokerage bucket, and it is the one most teams underestimate.

Intragroup transactions are in scope unless a specific exemption applies. Transactions with central banks of the ESCB are out of scope. Central counterparty cleared trades are in scope, but CCPs report their own leg. And here is the first place people get confused: a collateral arrangement on its own is not an SFT. A cleared derivative margined under a credit support annex is not an SFT. The driver is the product type, not the fact that securities or cash change hands.

The common mistake is to treat every securities transfer as potentially reportable. It is not. A title transfer collateral arrangement supporting an OTC derivative sits under EMIR, not SFTR. A securities lending transaction that funds that same collateral does sit under SFTR. Teams that run both EMIR and SFTR pipelines often end up double-counting the cash leg of a stock loan because somebody tried to squeeze the collateral movement into both flows.

Who has to report under SFTR

SFTR reporting is dual-sided. Both counterparties to an in-scope SFT report, each one to a registered trade repository, within T+1 of the trade, modification, collateral update, valuation, or termination. Article 4(1) of Regulation (EU) 2015/2365 is the operative text. The counterparty scope maps directly onto the phased go-live back in 2020 and 2021, and the phases still matter because they define which categories of firm were expected to have reporting live by which date:

• Phases 1 and 2 (13 July 2020): credit institutions, investment firms, CCPs and CSDs. The original plan split banks and investment firms from CCPs and CSDs across two phases, but ESMA merged them because of the COVID-related delay from the original April 2020 date.
• Phase 3 (12 October 2020): insurance and reinsurance undertakings, UCITS, AIFs, and institutions for occupational retirement provision (IORPs).
• Phase 4 (11 January 2021): non-financial counterparties (NFCs).

Reporting obligations do not sit with the trader. They sit with the legal entity that is a counterparty to the trade. For a Luxembourg UCITS fund using a prime broker, the fund itself is the counterparty. The management company does not own the obligation, the UCITS does, but under Article 4(3) the UCITS management company is responsible for ensuring the fund complies. In practice, that means the ManCo signs a delegated reporting agreement with the prime broker or a vendor, but the regulatory liability stays with the fund.

Article 4(3) is also where the AIFM obligation lives for alternative investment funds. Same mechanics: the AIF is the counterparty, the AIFM is responsible, and delegated reporting is the default operating model because no AIF runs its own T+1 trade repository feed. The trap here is assuming delegation discharges the fund from any day-to-day responsibility. It does not. The fund still has to monitor that the delegate is actually reporting, that exceptions are being cleared, and that reconciliation breaks are being investigated. A delegated reporting agreement that never gets audited is a finding waiting to happen.

Small non-financial counterparties get a quiet exemption most firms forget about. If an NFC falls below the Article 3 size threshold for two consecutive annual periods, the financial counterparty takes over both sides of the reporting under Article 4(3). For Luxembourg banks trading repo against small corporate treasuries, that means the bank reports on behalf of the corporate and still has to collect the LEI, the sector classification, and the lifecycle data as if the corporate were doing it itself.

What gets reported: the four tables

The technical standards under SFTR are Commission Delegated Regulation (EU) 2019/356 for the content of reports and Commission Implementing Regulation (EU) 2019/363 for the format and frequency. Together they define roughly 155 reportable fields split across four tables. Knowing which table drives which message type is the single most useful thing a new SFTR analyst can learn.

Table 1: Counterparty Data

The reporting counterparty, the other counterparty, the broker, the CCP and clearing member where applicable, the beneficiary, the tri-party agent, the agent lender, and the branch of each. This table is stable. It does not change trade by trade, it changes when the legal entity structure changes or a new prime broker relationship is signed. Every field is keyed to an LEI. An expired LEI on any of these entities invalidates the whole report, and the invalidation is not obvious until the trade repository sends back the reject.

Table 2: Loan and Collateral Data

The economic heart of the report. Trade type, master agreement reference, execution timestamp, value date, maturity date, principal amount, currency, rate, rebate, haircut, the security or cash being lent or pledged as collateral, quantity, nominal, market value, collateral quality, and whether the collateral is transferred on a net exposure or transaction-by-transaction basis. This is where the ambiguity lives. For tri-party repo, the collateral is typically reported at the net exposure level and updated daily. For bilateral repo, the collateral is reported transaction by transaction and is expected to match against what the counterparty reports on the same trade.

Table 3: Margin Data

Only relevant for CCP-cleared SFTs, and only for financial counterparties clearing through a CCP. Initial margin posted and received, variation margin posted and received, excess collateral, in the relevant currencies. Non-cleared SFTs do not populate this table. Teams occasionally try to squeeze bilateral repo variation margin into Table 3 because the label reads “margin”. That is wrong. Variation on a bilateral repo shows up as a collateral update in Table 2, not as margin in Table 3.

Table 4: Reuse, Cash Reinvestment and Funding Sources

Reuse data. The reporting counterparty reports, on a portfolio basis, the value of collateral available for reuse, the value actually reused, and the cash reinvestment data if it reinvests cash collateral. This table is reported at the entity and currency level, not at the trade level, which makes it the weirdest part of SFTR for anyone who thinks of reporting as “one message per trade”. Reuse is one message per counterparty per currency per day, even if nothing moved. That is a conceptual mismatch most vendor systems handle with a dedicated module, and it is where internal audit tends to pick the easy finding in year-two reviews.

Lifecycle events and action types

SFTR is a lifecycle report, not a “one and done” report. Every state change on a trade produces a new message, each with its own action type, until the trade is either terminated or corrected away. The action types defined in the ITS are:

• NEWT (new trade) on T+1 of execution.
• MODI (modification) when any non-valuation field changes.
• VALU (valuation update) daily for outstanding open repos and stock loans, reflecting mark-to-market and accrued rate.
• COLU (collateral update) when the collateral basket, haircut or composition changes, or daily for tri-party structures.
• MARU (margin update) daily for cleared SFTs.
• REUU (reuse update) at the portfolio level on the reporting day.
• ETRM (early termination) or the standard termination when the trade reaches maturity without a physical settlement fail.
• CORR (correction) when a prior message was incorrect and needs to be replaced.
• EROR (error) for a full cancel of a trade that should not have been reported at all.
• POSC (position component) for trades that are managed as a position and not individually.

The daily rhythm matters. An open repo rolling for six months generates up to one VALU, one COLU, and potentially one MARU every business day for six months. That is roughly 390 lifecycle messages per trade before termination, not counting the initial NEWT and any MODIs. Multiply by the book, and the volume problem is obvious. A mid-sized Luxembourg prime brokerage book can produce more lifecycle messages per week than the entire EMIR trade book of the same bank.

The place teams get hurt is the interaction between MODI and VALU. A field like “floating rate reference period” is classed as an economic term, so it flows as a MODI. A change in mark-to-market value is not economic, it flows as a VALU. Misclassify once and the trade repository rejects it as duplicative against yesterday’s VALU, the operations team reprocesses it as a MODI, it rejects again because the modification date does not line up, and you are in a three-way loop with the repository and the counterparty that only a phone call ends.

UTIs, LEIs and why the trade identifier is the whole game

The Unique Transaction Identifier is the pivot the entire SFTR pipeline turns on. Both sides of an in-scope SFT must report using the same UTI. If they do not, reconciliation fails on message one and every subsequent lifecycle message piles up in the breaks queue. UTI generation follows an ESMA-defined waterfall: in the absence of a CCP or electronic confirmation platform generating the UTI, responsibility falls on the financial counterparty against a non-financial counterparty, or on the seller against the buyer in a repo, or on the lender against the borrower in a stock loan. The waterfall is documented in the ESMA reporting guidelines on SFTR.

The practical problem is that waterfalls only work when both counterparties implement them the same way. In bilateral dealer-to-dealer repo, one side often generates the UTI from its front office system at trade capture, the other side waits for the confirmation message, and they end up with two different UTIs for the same trade. Resolution typically involves a manual UTI cascade email at the close of business, which is not a scalable control.

LEIs are the second identifier that matters. Every legal entity in Table 1 needs a current, non-expired LEI on the report date. The ESMA “no LEI, no trade” principle from the MiFIR world has a near-equivalent force in SFTR: a report with an expired LEI for any party is invalid, and the trade repository will reject it. LEI renewal is an annual calendar event the counterparty management team is supposed to own, but in practice the reporting team is the first to notice the expiry because the rejects come to them first. A simple T minus 30 days expiry alert against the GLEIF database catches 80 percent of these problems before they become rejects.

Reconciliation and data quality

Because SFTR is dual-sided, reconciliation is done by the trade repositories on a daily basis and the results are fed back to both counterparties. Reconciliation is a two-stage process, and mixing up the stages is one of the fastest ways to make an SFTR review meeting unproductive.

Stage one: pairing

Pairing is the trade repository matching the two reports to confirm they are describing the same trade. It uses a subset of fields including the two LEIs, the UTI, and the action type. A trade pairs or it does not. If it does not pair, one of the two reports is either missing, sent to a different repository, or has a UTI typo. Unpaired trades are the first break to chase every morning, because everything downstream depends on pairing succeeding.

Stage two: matching

Matching is the trade repository comparing the economic fields between the two paired reports and flagging any that do not agree within tolerance. ESMA rolled matching out in phases, starting with a small set of fields and progressively adding more over time. The current matched-fields set covers most economic terms, all key dates, the collateral value with tolerance, and the principal amount. The unmatched-fields set covers items that are hard to reconcile in practice like internal timestamps and some free-text fields.

The common misconception is that “unmatched” means “safe to ignore”. It does not. An unmatched field still appears in the reconciliation feedback and still counts towards the data quality indicator the national competent authority monitors. The fact that it does not block reporting does not mean the regulator has stopped looking at it. CSSF and ESMA both cite reconciliation rates as part of their supervisory data quality work, and a persistent unmatched-fields pattern is the kind of thing that ends up in a thematic review.

The operational issue with matching is tolerance. Collateral market value tolerance exists because two counterparties using two different pricing sources will always price the same bond differently. Rates, haircuts and principal amounts have no tolerance, because they are economic terms agreed in writing. A break on the haircut is never a pricing issue, it is always a booking issue on one side or the other. Distinguish the two types of breaks at the start of the investigation and you close them faster.

The Luxembourg angle

CSSF is the competent authority for SFTR in Luxembourg, which means CSSF receives the ESMA-aggregated data quality indicators for any entity it supervises, and CSSF is the entity that handles on-site inspections where SFTR features. For the bulk of the Luxembourg fund industry, the operating model is delegation to the prime broker, to the depositary, or to a specialist vendor. That means the practical reporting risks for a UCITS or AIF are less about the reporting software and more about the oversight of the delegate.

Three specific Luxembourg-flavoured pain points come up again and again.

First, master-feeder structures. A Luxembourg master fund with multiple feeders across the EU and the UK can end up with different reporting obligations at the feeder level depending on whether the feeder is an AIF, a UCITS or neither, and whether the feeder is UK-domiciled after Brexit. UK SFTR diverged from EU SFTR in scope and technical standards, and any UK feeder reporting to the FCA does not discharge the Luxembourg master’s EU obligation. Treat the two regimes as separate pipelines even when the underlying trades are the same.

Second, tri-party collateral management via Clearstream and other Luxembourg-based tri-party agents. Tri-party structures make the NEWT message straightforward and the COLU messages difficult, because the collateral basket composition changes intraday and only the tri-party agent knows the final end-of-day snapshot. If the fund’s reporting delegate receives the tri-party file late, the T+1 deadline slides, and you end up reporting yesterday’s collateral today. There is no flag for “data received late from tri-party”, so the message goes out with a valuation date that looks wrong to the regulator.

Third, the SICAV with a prime broker that is not an EU entity. If the prime broker is not a counterparty to an EU reporting obligation, the Luxembourg SICAV is on its own for its side of the trade, and the delegated reporting agreement has to cover the work the non-EU prime broker would otherwise do automatically. I have seen this structure collapse the moment the prime broker moved reporting operations offshore and the SICAV’s delegate discovered it was no longer receiving the paired file. The fix was not complicated. Nobody had mapped the dependency until the first month of breaks.

Common operational pain points

After several years of live SFTR reporting, the issues that keep showing up are not the exotic ones from the original implementation projects. They are the boring ones that stay broken because nobody owns them.

Trade capture timing

Front office systems book repo and stock loan trades at execution, but they often write the full field set only at end of day, after a batch enrichment step. If the batch runs late, the T+1 SFTR report misses its deadline. The fix is to feed the SFTR pipeline directly from the trade capture event, not from the end-of-day snapshot, and to accept that some fields will be enriched later via a MODI. This is a design call most banks made during the SFTR project and then quietly walked back because the MODI volumes were uncomfortable.

Master agreement references

SFTR requires a master agreement reference field. It expects a code from an ESMA-maintained list: GMRA, GMSLA, OSLA, MSLA, MEFI, MRA, DERV, ISDA, and a residual “OTHR” for anything that does not map. Teams misuse OTHR. A trade booked under a non-standard Luxembourg bilateral agreement is not automatically OTHR, it might actually map to one of the specified codes with a minor local addendum. Persistent OTHR usage looks lazy to a reviewer and draws a question in any supervisory conversation.

Collateral identification

Collateral has to be identified by ISIN when possible, or by CFI code and issuer LEI when not. Cash collateral has its own treatment. The trap is bond fungibility: a security that has been through a corporate action sometimes sits in the firm’s books under an old ISIN, while the counterparty booked it under the new one. The trade pairs but the collateral field does not match, and the break stays open until somebody realises the two ISINs describe the same underlying paper.

Valuation source consistency

The valuation field requires a mark-to-market or mark-to-model value. If the firm uses its own internal price for the valuation, and the counterparty uses a third-party pricing vendor, the two values will never match exactly. Tolerance covers most of this, but tolerance does not cover everything and the regulator sees the persistent small differences. The pragmatic fix is to align the pricing source with the counterparty’s source for the most material positions, even if the internal risk system uses a different price. Two pricing feeds is unpleasant. Three is where teams start losing track.

Error handling and backloading

The original SFTR go-live required some backloading of open trades from before the phase-in date. That exercise is long closed. What is not closed is the error correction pipeline. Every reporting team has a backlog of historical corrections, CORR messages, and cancels they never got around to clearing because the exceptions are old and the counterparties have changed systems. The reconciliation feedback keeps surfacing them, and internal audit keeps noting them. The only way out is a scheduled cleanup sweep, not a “we will catch them as they come” policy, because they do not come. They accumulate.

Why firms still struggle with SFTR reporting

Six years in, SFTR reporting is not a solved problem for most of the EU market. The reasons are not technical. The trade repositories work, the ISO 20022 schemas are stable, the vendor solutions are mature. The reasons are operational, and they cluster around three things.

The first is that SFTR sits at the seam between front office, operations, collateral management and regulatory reporting. No single team owns all the data and no single team wants the escalation. A break on the haircut field touches front office because front office negotiated the haircut, collateral management because collateral management confirmed the valuation, operations because operations booked the trade, and reporting because reporting produced the message. The break sits in reporting’s queue and reporting has to chase three other teams to close it. Firms that solved this created a small SFTR reconciliation team with authority to raise tickets directly against any of the four functions. Firms that did not are still chasing the same breaks every week.

The second is delegation fatigue. The Luxembourg fund industry runs on delegated reporting, and delegated reporting works until it stops working. When the delegate makes a systemic error, the fund is the one on the hook. Oversight of the delegate tends to start strong and decay over eighteen months to a quarterly review based on a one-page dashboard. That is not enough. At minimum, the ManCo or AIFM should see the reconciliation failure rate by field, the unpaired trade count, and the delegate’s own rejection log. A single-number “reporting OK” indicator hides the problems that cost you in a thematic review.

The third is that SFTR is rarely a strategic priority inside a bank or fund. It does not drive revenue, it does not affect capital, and it does not stop trading when it fails. It accumulates small, persistent data quality problems that only an audit or a regulator flags. The budget conversation for a proper SFTR remediation project always loses to the conversation about the next CRR3 or DORA deliverable. This is how the same reconciliation break shows up in the quarterly report for eight quarters in a row without anyone being allowed to actually fix it.

Frequently Asked Questions

Is intragroup lending exempt from SFTR reporting?

No, not by default. Intragroup SFTs are in scope unless a specific exemption under Article 3 or the counterparty concession under Article 4(3) applies. The reporting counterparty still has to file, even when the trade is economically immaterial at group level. Teams sometimes assume intragroup is exempt by analogy with EMIR, which has its own intragroup exemption under Article 3 of EMIR. SFTR and EMIR do not share that exemption mechanic.

What happens if we miss the T+1 deadline?

The report becomes late. A late report is still a reported trade and should be filed as soon as the data is complete, with the action type reflecting the current state of the trade. The trade repository will accept it. The national competent authority will see the late submission in the data quality indicator feed, and persistent lateness is flagged in the supervisory conversation. The right response to a late report is to file it, not to suppress it and hope the reconciliation never notices.

Do UCITS and AIFs have to set up their own trade repository connection?

In practice, no. The default operating model is delegated reporting through the prime broker, the depositary, or a specialist vendor. The management company signs the delegation agreement and the fund pays for the service. The regulatory obligation under Article 4(3) stays with the AIFM or UCITS management company, so delegation is an operational choice, not a transfer of liability.

How are buy-sell back transactions reported differently from repos?

Economically they are similar, but SFTR treats them as a single buy-sell back trade type with its own code, not as two separate outright cash trades. The value date, maturity date and repurchase rate fields are filled even though the underlying legal documentation might be two separate trades. This is one of the few places where SFTR collapses the legal form into the economic form for reporting purposes.

What is the difference between pairing and matching in SFTR reconciliation?

Pairing is the trade repository confirming that both sides sent a report for the same trade, using the LEI pair, the UTI and the action type. Matching is the repository comparing the economic fields on the two paired reports and flagging any that disagree beyond tolerance. Pairing is binary: the trade paired or it did not. Matching is per field: the trade can be paired and still have ten unmatched fields.

Does SFTR apply to UK counterparties after Brexit?

UK SFTR diverged from EU SFTR. A UK entity trading with an EU entity reports its side to the FCA under UK SFTR, and the EU entity reports its side to an EU trade repository under EU SFTR. The two reports do not reconcile against each other through the EU trade repository network. Treat the two as parallel pipelines with different scope refinements in each jurisdiction.

How is reuse of collateral reported?

Reuse is reported at the portfolio level, not the trade level, in Table 4. The reporting counterparty files one reuse record per day per counterparty and currency, showing the collateral available for reuse, the value actually reused, and any reinvestment of cash collateral. The record is required even when the reuse figure is zero on a given day, because the absence of a message cannot be distinguished from a missing report.

Who is responsible when the delegated reporting agent makes a systemic error?

The legal counterparty to the trade. The delegation agreement allocates operational responsibility and may allocate financial liability, but the regulator’s interlocutor is the counterparty, which for a UCITS or AIF is the management company under Article 4(3). A delegate’s systemic error becomes the fund’s regulatory problem the moment the CSSF or another competent authority asks for an explanation.

Related Articles

• EMIR Reporting Explained – A walkthrough of the EU derivatives reporting regime, sister framework to SFTR, with overlapping counterparty logic and a separate trade repository pipeline.
• MiFIR Transaction Reporting – The third pillar of EU transaction reporting, covering cash market trades in financial instruments, and the place where “no LEI, no trade” first became policy.
• EMIR Initial Margin Reporting – The margin reporting angle on derivatives, useful context for understanding how SFTR Table 3 relates to the cleared margin world.
• CSSF Reporting Calendar Q2 2026 – The Luxembourg quarterly calendar including SFTR-relevant deadlines and competent authority checkpoints.

Key Takeaways

• SFTR reporting covers four product types only: repos, securities lending and borrowing, buy-sell backs, and margin lending. Everything else sits under another framework.
• Both counterparties report to a trade repository within T+1, using the same UTI, and the repositories reconcile the two sides daily.
• The four reportable tables are Counterparty Data, Loan and Collateral Data, Margin Data (cleared only), and Reuse Data. Reuse is reported at entity level, not trade level.
• UCITS and AIFs almost always delegate the reporting work, but the UCITS management company or AIFM remains responsible under Article 4(3).
• Reconciliation happens in two stages, pairing and matching, and the distinction matters when investigating breaks.
• The common operational failures are trade capture timing, master agreement mis-coding, collateral ISIN mismatches across corporate actions, and unchecked delegation oversight.
• CSSF supervises SFTR compliance for Luxembourg-incorporated counterparties and reads the ESMA data quality indicators as part of its regular supervisory work.
• UK SFTR and EU SFTR are separate regimes after Brexit. A UK report to the FCA does not discharge an EU counterparty’s obligation to an EU trade repository.

Sources and References

• 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 (SFTR)
• Commission Delegated Regulation (EU) 2019/356 on regulatory technical standards specifying the details of SFTs to be reported to trade repositories
• Commission Implementing Regulation (EU) 2019/363 on implementing technical standards on the format and frequency of reports on SFTs to trade repositories
• European Securities and Markets Authority (ESMA) – SFTR reporting guidelines and validation rules
• Commission de Surveillance du Secteur Financier (CSSF) – Luxembourg competent authority for SFTR
• Global Legal Entity Identifier Foundation (GLEIF) – LEI lookup and renewal

Where SFTR reporting breaks and where to aim

If there is one test for whether a firm’s SFTR reporting is healthy, it is not the go-live date and it is not the number of trades filed on time. It is the age of the oldest open reconciliation break and the frequency with which the same field turns up in the weekly exception report. A reporting pipeline that files every trade on time but carries the same ten persistent breaks every week is not working. It is shipping noise. The move that separates functional SFTR operations from dysfunctional ones is building the ownership model that lets somebody actually close those breaks. Technology will not do it. The regulation does not care who does it. But the data quality indicators feed CSSF every week, and the first question in a thematic review is always the same one: what are you doing about the breaks you already know about?

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.