Assessing your SFTR reporting build
27 June 2019
Jonathan Lee of Kaizen Reporting discusses how to make an honest assessment on the quality of your firm鈥檚 SFTR reporting
Image: Shutterstock
Congratulations! You鈥檝e got the project over the finishing line and built your SFTR reporting infrastructure. Is it now time to take an independent, honest assessment of the quality of your reporting?
In many instances, new regulatory reporting deliveries have been about getting the project across the line. Initial ambitious plans to have fully reconciled data and controls frameworks in place have been paired back. A lack of time (complex project planning), lack of resources, or in some cases, lack of opportunity to deploy as many resources as were budgeted for are all reasons cited for a lack of initial controls. This last situation occurs as too many institutions chase too few developers and subject matter experts in the clamour to build for new regulation.
In the midst of just getting reports out of the door, there are a number of questions that have come to light. Have controls been de-prioritised or deemed 鈥榙ay two鈥� deliveries at your institution? Have temporary deferrals been applied for encompassing aspects of the delivery with your national competent authority (NCA)? Do you have appropriate reconciliations in place internally? Are data guardians, accountable owners for every data point in your SFTR reports? Hand on heart, have you done enough testing? Do you have regression packs ready to test the impact of all new business deliveries on your SFTR reporting flows going forward?
Lost in the delivery?
It is a commonly held view that approximately 40 percent of SFTR fields are challenging to obtain. Nevertheless, we would urge that you do not sacrifice data quality in pursuit of populating all fields correctly or allowing your vendor reporting service to make incorrect assumptions in pursuit of a complete report. There is a temptation during the planning and build phase to see an instance of value somewhere in the production stack of internal systems that appears to be applicable and to configure reports to use that value. These quick fixes or Elastoplast鈥檚 if you like, are often stale, unverified and not validated. Be wary of using data sources where data ownership and governance are unclear and adequate controls around the data points are not in place.
10 tests of the quality of your SFTR delivery
Here is just a sample of questions that you should be asking about your SFTR delivery:
鈥� Does your reporting capture every trade in your risk systems?
鈥� Is every lifecycle event accounted for?
鈥� Are you able to send daily collateral updates to reflect changes in collateral value on open trades?
鈥� Are you reporting trades facing every lender by close of business execution date plus one once the allocations have been received?
鈥� Are lender changes accurately captured in your reporting?
鈥� Are you accurately reporting every line of collateral in triparty securities lending and repo trades by settlement date plus one and each overnight collateral allocation for those trades?
鈥� Are you capturing transactions entered into through auto and self-collateralisation and auto borrowing and lending programmes at the central securities depositories or sub-custodians?
鈥� Do all of your trades pass the trade repository validations?
鈥� Are you seeing significant volumes of alleged trades from the trade repository post-TR reconciliation highlighting gaps in your reporting?
鈥� Do you have correct securities issuer legal entity identifiers (LEIs)? CFI codes? collateral type?
If you are delegating your SFTR reporting, how much visibility do you receive in relation to these areas from the reporting party?
A recap on what regulators are trying to achieve
Tackling concerns about the role of securities financing markets in the last financial crisis and fears that they might be at the centre of the next financial crisis led securities financing transaction reporting to become a top G20 agenda point and one of the last to be tackled post-crisis.
SFTR is based on the G20 Financial Stability Board鈥檚 (FSB) work on 鈥淭ransforming Shadow Banking into Resilient Market-based Finance: Standards and processes for global securities financing data collection and aggregation鈥�. A lot of concern has been expressed about shadow banking and collateral reuse. Specific objectives raised focus on tackling a lack of transparency, spotting build ups on leverage, identifying interconnectedness and addressing concerns about the pro-cyclical nature of SFT markets.
What does this mean for reporting firms?
It is no coincidence that SFTR reporting is closely modelled on the European Markets Infrastructure Regulation (EMIR) reporting. Both of these regimes were born out of the G20 FSB remit to tackle the last financial crisis and help prevent the next financial crisis. The majority of the objectives are the same.
The local competent authorities require the data to meet macro-prudential requirements at a national and European level in conjunction with the European System of Central Banks (ESCB) global level. The aim is to achieve this in the most efficient and cost-effective way given severe resource limitations.
Essentially, regulators are expecting to be spoon-fed鈥攏ot only details of all transactions, collateral, lifecycle events, master agreements, but also industry standards for identifiers for all nine potential parties to a transaction, instrument identifiers, security issuer LEIs, unique trade identifiers, rate indices, haircuts, nominal, price per unit and minimum notice periods. In addition to all of this, they are also expecting a whole host of classification data.
On top of all of the economics and industry standard identifiers, they also require: country of other counterparty, actual rates, earliest call back dates, whether the collateral is general collateral or specific, method used to provide collateral, the principal amount on value date, collateral market value, maturity dates for collateral securities, the credit quality of those securities, classification of a security (CFI code), collateral type classification and the availability for re-use.
They want all of this information in the most digestible, paired and matched state (to avoid double counting) in order to meet their regulatory objectives as soon and as easily as possible. Anything that prevents regulators from achieving that objective will at best need correcting/back reporting and at worst will be subject to fines, public disclosure and possibly legal measures taken against a business or responsible senior managers.
History of enforcement actions for other transaction reporting regimes
The UK Financial Conduct Authority (FCA) alone lists 14 transaction reporting related fines over the past decade. This does not include the largest ever fine and first fine levied by the FCA for EMIR reporting failures; 拢34.5 million in October 2017. The EMIR fine and the commentary attached are most applicable to SFTR. The fact that two firms got fined a total of 拢61.9 million during March 2019 makes this all the more topical. These fines also do little to illustrate the much larger number of firms that have been subject to lengthy and expensive section 166 skilled person review, external audits, remediation efforts and back reporting.
Lessons from enforcement actions
The text of the EMIR fine cited the following, which we believe to be equally applicable to SFTR: 鈥渢he reporting requirements introduced under EMIR were an important component in addressing uncertainty around systemic financial risk, caused by a lack of transparency. The FCA directly communicated the importance of EMIR reporting requirements to firms in a variety of ways [...] and the authority has published a number of enforcement actions taken in relation to similar failings by other firms in relation to other categories of transaction reporting.鈥�
The misdemeanours that the FCA has repeatedly picked up on are:
鈥� Failing to have adequate systems and controls to ensure that reference or 鈥榮tatic鈥� data used for various mandatory fields in the transaction reports submitted to the authority were complete and accurate;
鈥� Failing to have in place adequate change management controls to manage changes affecting transaction reporting processes and systems, and
鈥� Failing to undertake appropriate testing to ensure the completeness and accuracy of transaction reports. Most recent notices have called out the inadequacies of periodic and sample-based testing鈥攆irms need to test their whole universes.
鈥� Failing to allocate adequate and sufficient appropriately trained human resource to undertake its obligations to report.
In Kaizen鈥檚 experience, regulatory reporting data quality is an industry-wide problem (example form MiFID II). In the graphic, we summarise the 405 million issues we have identified after testing over 221 million records in the last year.
Keeping your nose clean
The obvious lesson is that the FCA and other NCAs are actively enforcing transaction reporting. If your firm does not have adequate systems and controls in place or doesn鈥檛 even know how good (or bad) its reporting is; you could be at risk.
Ensuring that operations, compliance and the business are adequately trained on SFTR will be a significant first step towards ensuring compliance. Ownership and governance need to be in place to ensure accountability for the reporting itself and all of the underlying data points. SFTR development resources should be retained post-go-live to aid the inevitable necessary remediation efforts.
We also recommend giving serious consideration to outsourcing the controls layer. This can provide a great deal of peace of mind and cover off on your senior manager and certification regime requirements in addition to basic SFTR compliance. Vendor solutions can offer economies of scale, independent, impartial experience and expertise. Regulatory testing service offerings such as Kaizen鈥檚 ensure that nobody is marking their own homework and that every transaction report, lifecycle event and field is thoroughly tested. Not based on a sample, we can help ensure full end-to-end completeness and accuracy of your SFTR reporting.
In many instances, new regulatory reporting deliveries have been about getting the project across the line. Initial ambitious plans to have fully reconciled data and controls frameworks in place have been paired back. A lack of time (complex project planning), lack of resources, or in some cases, lack of opportunity to deploy as many resources as were budgeted for are all reasons cited for a lack of initial controls. This last situation occurs as too many institutions chase too few developers and subject matter experts in the clamour to build for new regulation.
In the midst of just getting reports out of the door, there are a number of questions that have come to light. Have controls been de-prioritised or deemed 鈥榙ay two鈥� deliveries at your institution? Have temporary deferrals been applied for encompassing aspects of the delivery with your national competent authority (NCA)? Do you have appropriate reconciliations in place internally? Are data guardians, accountable owners for every data point in your SFTR reports? Hand on heart, have you done enough testing? Do you have regression packs ready to test the impact of all new business deliveries on your SFTR reporting flows going forward?
Lost in the delivery?
It is a commonly held view that approximately 40 percent of SFTR fields are challenging to obtain. Nevertheless, we would urge that you do not sacrifice data quality in pursuit of populating all fields correctly or allowing your vendor reporting service to make incorrect assumptions in pursuit of a complete report. There is a temptation during the planning and build phase to see an instance of value somewhere in the production stack of internal systems that appears to be applicable and to configure reports to use that value. These quick fixes or Elastoplast鈥檚 if you like, are often stale, unverified and not validated. Be wary of using data sources where data ownership and governance are unclear and adequate controls around the data points are not in place.
10 tests of the quality of your SFTR delivery
Here is just a sample of questions that you should be asking about your SFTR delivery:
鈥� Does your reporting capture every trade in your risk systems?
鈥� Is every lifecycle event accounted for?
鈥� Are you able to send daily collateral updates to reflect changes in collateral value on open trades?
鈥� Are you reporting trades facing every lender by close of business execution date plus one once the allocations have been received?
鈥� Are lender changes accurately captured in your reporting?
鈥� Are you accurately reporting every line of collateral in triparty securities lending and repo trades by settlement date plus one and each overnight collateral allocation for those trades?
鈥� Are you capturing transactions entered into through auto and self-collateralisation and auto borrowing and lending programmes at the central securities depositories or sub-custodians?
鈥� Do all of your trades pass the trade repository validations?
鈥� Are you seeing significant volumes of alleged trades from the trade repository post-TR reconciliation highlighting gaps in your reporting?
鈥� Do you have correct securities issuer legal entity identifiers (LEIs)? CFI codes? collateral type?
If you are delegating your SFTR reporting, how much visibility do you receive in relation to these areas from the reporting party?
A recap on what regulators are trying to achieve
Tackling concerns about the role of securities financing markets in the last financial crisis and fears that they might be at the centre of the next financial crisis led securities financing transaction reporting to become a top G20 agenda point and one of the last to be tackled post-crisis.
SFTR is based on the G20 Financial Stability Board鈥檚 (FSB) work on 鈥淭ransforming Shadow Banking into Resilient Market-based Finance: Standards and processes for global securities financing data collection and aggregation鈥�. A lot of concern has been expressed about shadow banking and collateral reuse. Specific objectives raised focus on tackling a lack of transparency, spotting build ups on leverage, identifying interconnectedness and addressing concerns about the pro-cyclical nature of SFT markets.
What does this mean for reporting firms?
It is no coincidence that SFTR reporting is closely modelled on the European Markets Infrastructure Regulation (EMIR) reporting. Both of these regimes were born out of the G20 FSB remit to tackle the last financial crisis and help prevent the next financial crisis. The majority of the objectives are the same.
The local competent authorities require the data to meet macro-prudential requirements at a national and European level in conjunction with the European System of Central Banks (ESCB) global level. The aim is to achieve this in the most efficient and cost-effective way given severe resource limitations.
Essentially, regulators are expecting to be spoon-fed鈥攏ot only details of all transactions, collateral, lifecycle events, master agreements, but also industry standards for identifiers for all nine potential parties to a transaction, instrument identifiers, security issuer LEIs, unique trade identifiers, rate indices, haircuts, nominal, price per unit and minimum notice periods. In addition to all of this, they are also expecting a whole host of classification data.
On top of all of the economics and industry standard identifiers, they also require: country of other counterparty, actual rates, earliest call back dates, whether the collateral is general collateral or specific, method used to provide collateral, the principal amount on value date, collateral market value, maturity dates for collateral securities, the credit quality of those securities, classification of a security (CFI code), collateral type classification and the availability for re-use.
They want all of this information in the most digestible, paired and matched state (to avoid double counting) in order to meet their regulatory objectives as soon and as easily as possible. Anything that prevents regulators from achieving that objective will at best need correcting/back reporting and at worst will be subject to fines, public disclosure and possibly legal measures taken against a business or responsible senior managers.
History of enforcement actions for other transaction reporting regimes
The UK Financial Conduct Authority (FCA) alone lists 14 transaction reporting related fines over the past decade. This does not include the largest ever fine and first fine levied by the FCA for EMIR reporting failures; 拢34.5 million in October 2017. The EMIR fine and the commentary attached are most applicable to SFTR. The fact that two firms got fined a total of 拢61.9 million during March 2019 makes this all the more topical. These fines also do little to illustrate the much larger number of firms that have been subject to lengthy and expensive section 166 skilled person review, external audits, remediation efforts and back reporting.
Lessons from enforcement actions
The text of the EMIR fine cited the following, which we believe to be equally applicable to SFTR: 鈥渢he reporting requirements introduced under EMIR were an important component in addressing uncertainty around systemic financial risk, caused by a lack of transparency. The FCA directly communicated the importance of EMIR reporting requirements to firms in a variety of ways [...] and the authority has published a number of enforcement actions taken in relation to similar failings by other firms in relation to other categories of transaction reporting.鈥�
The misdemeanours that the FCA has repeatedly picked up on are:
鈥� Failing to have adequate systems and controls to ensure that reference or 鈥榮tatic鈥� data used for various mandatory fields in the transaction reports submitted to the authority were complete and accurate;
鈥� Failing to have in place adequate change management controls to manage changes affecting transaction reporting processes and systems, and
鈥� Failing to undertake appropriate testing to ensure the completeness and accuracy of transaction reports. Most recent notices have called out the inadequacies of periodic and sample-based testing鈥攆irms need to test their whole universes.
鈥� Failing to allocate adequate and sufficient appropriately trained human resource to undertake its obligations to report.
In Kaizen鈥檚 experience, regulatory reporting data quality is an industry-wide problem (example form MiFID II). In the graphic, we summarise the 405 million issues we have identified after testing over 221 million records in the last year.
Keeping your nose clean
The obvious lesson is that the FCA and other NCAs are actively enforcing transaction reporting. If your firm does not have adequate systems and controls in place or doesn鈥檛 even know how good (or bad) its reporting is; you could be at risk.
Ensuring that operations, compliance and the business are adequately trained on SFTR will be a significant first step towards ensuring compliance. Ownership and governance need to be in place to ensure accountability for the reporting itself and all of the underlying data points. SFTR development resources should be retained post-go-live to aid the inevitable necessary remediation efforts.
We also recommend giving serious consideration to outsourcing the controls layer. This can provide a great deal of peace of mind and cover off on your senior manager and certification regime requirements in addition to basic SFTR compliance. Vendor solutions can offer economies of scale, independent, impartial experience and expertise. Regulatory testing service offerings such as Kaizen鈥檚 ensure that nobody is marking their own homework and that every transaction report, lifecycle event and field is thoroughly tested. Not based on a sample, we can help ensure full end-to-end completeness and accuracy of your SFTR reporting.
NO FEE, NO RISK
100% ON RETURNS If you invest in only one securities finance news source this year, make sure it is your free subscription to 网爆吃瓜 Finance Times
100% ON RETURNS If you invest in only one securities finance news source this year, make sure it is your free subscription to 网爆吃瓜 Finance Times
