=Paper=
{{Paper
|id=Vol-2049/03paper
|storemode=property
|title=Mapping Cross-Border Margin Requirements
|pdfUrl=https://ceur-ws.org/Vol-2049/03paper.pdf
|volume=Vol-2049
|authors=Jim Baird
|dblpUrl=https://dblp.org/rec/conf/jurix/Baird17
}}
==Mapping Cross-Border Margin Requirements==
https://ceur-ws.org/Vol-2049/03paper.pdf
Proceedings of the 1st Workshop on Technologies for Regulatory Compliance
Mapping Cross-Border Margin Requirements
Jim Baird1
1
EMRiLs Limited, UK
info@emrils.co.uk
Abstract. The Financial Crisis of 2007-8 triggered a large-scale overhaul of
European and Global Financial Services Regulation. Financial institutions are
now subject to more far-reaching and onerous regulation, as well as the
prospect of increased regulatory fines. The European Market Infrastructure
Regulation (“EMIR”) (and parallel regimes in other G20 members countries) is
part of this new landscape. With the aim of reducing counterparty and systemic
risk, EMIR requires that so called “over-the-counter” derivative transactions are
either cleared through a central counterparty, or that the parties (including
certain non-financial entities) exchange collateral and undertake other risk-
mitigating measures. EU entities conducting over-the-counter derivative
transactions and their non-EU counterparties must reconcile the EU rules with
those that apply in the non-EU counterpart’s jurisdiction. The position in any
given case will depend on numerous variables including the jurisdiction of the
counterparty, the nature of the transaction, the collateral that would be provided
and whether and to what extent the EU Commission has determined that the
rules in the third country are equivalent to those in the EU. This paper outlines
the needs of EU market participants in the context of this complex and evolving
regulatory matrix and suggests key areas in which technology solutions may
address those needs.
1. Background
The Financial Crisis of 2007-8 triggered a far-reaching overhaul of European and
Global Financial Services Regulation which, some 10 years later, is still in progress.
During that time, banks and other financial institutions have been implementing a
greatly increased volume of regulation. At the same time, there has been an upward
trend in the quantum of regulatory fines, both in terms of the statutory maxima, and
those imposed in practice.
The regulatory initiatives have focussed on key problem areas, in particular: investor
protection and transparency, market stability and reduction of counterparty and
systemic risk.
One major element of the regulatory initiatives is the European Market Infrastructure
Regulation (“EMIR”) [1] and the equivalent regimes in other G20 members countries
(which resulted from a 2009 G20 Commitment to reduce, among other things,
counterparty and systemic risk). EMIR introduces various requirements on entities
19
Proceedings of the 1st Workshop on Technologies for Regulatory Compliance
that trade in so-called “over-the-counter” or “OTC” derivatives (outlined in more
detail below).
While EMIR is aimed primarily at financial institutions, it also impacts certain non-
financial entities. Many financial entities impacted by the Regulation will have the
significant human, operational and financial resource to address compliance with
these complex regulations. However, non-financial and smaller financial entities that
are within scope may not have adequate resource and may find the regulations to be a
barrier (or at least a hurdle) to accessing the international markets.
2. What do EMIR and Parallel Regimes Require?
EMIR and the parallel regimes in other G20 countries introduce three main elements.
First, a requirement for OTC derivatives to be cleared through a central counterparty.
Only derivatives that are significantly commoditised/standardised are required to be
centrally cleared.
Second, a requirement for certain risk mitigation measures to be implemented – in
particular the exchange of margin - in relation to transactions that are not centrally
cleared (typically less standardised transactions) but nonetheless fall within the scope
of EMIR. Finally, OTC transactions are required to be reported to trade repositories.
3. What Structural Issues do EU Entities Face?
It is common for entities to rely on the systems and/or information reporting of their
trade counterpart in complying with these regulations. However, difficulties can arise
because systems and compliance procedures of the delegate are naturally configured
to the application of the regulations to the delegate.
For example, the definition of “derivative” may differ between EU and non-EU
jurisdictions (and even between EU jurisdictions) with the risk of under- or over-
reporting if relying only on one of the parties’ systems.
Similarly, one party’s system is designed to support real-time reporting (as required
under the US parallel regime), whereas an EU counterpart may be required to report
on an end-of-day basis. This may make effective reliance on one party’s system
impracticable. For example, under an end-of-day regime, a cancelled trade may not be
reported at all but under a real-time system would be reported and a cancellation
report filed. Similar differences arise in the context of supplementing trade entry data
with valuation and collateral/margin data.
It can be hard for a delegating entity to have good visibility as to the underlying
regulatory rationale and assumptions implicit in the system developed by the
20
Proceedings of the 1st Workshop on Technologies for Regulatory Compliance
counterparty it relies upon. This can create difficulties for delegating entities in
validating that the actions taken or data provided by their delegates.
At the same time, there is still a prevalence of bespoke, proprietary data models and
schema and collaboration in relation to standardisation of schema and data models is
still lagging. This inhibits optimal interoperability between systems both between
counterparties and also between clients and various service providers such as
compliance consultants, lawyers, accountants, consultants etc.
4. How Can Lynx Help?
As a single, central, maintained knowledgebase, Lynx could act as the “rules layer”
that informs a more dynamic data and knowledge driven trading infrastructure across
international markets.
Rather than building rigid systems based on a “regulatory snapshot” at build time,
systems designed around a knowledge-centric model can be more responsive and
dynamic. “Responsive” in the sense that a regulatory change (such as amendment of
primary or secondary rules or a new equivalence determination) would require an
update to the central knowledge base and only modest re-configuration of the trading
and related systems. “Dynamic” in the sense that such a system could “model” the
financial and compliance impact of proposed trades in near real time to determine the
optimal structure (counterparty, regime selection, type of margin, etc).
Entities relying on their trading counterparties for elements of compliance would be
better able to validate the appropriateness of the service they receive from their
counterparty by querying the knowledgebase, again in near real time.
A central knowledgebase would help to propagate the use of common schema and
ontologies across the industry. This would provide further commercial opportunities
for service providers (compliance consultants, lawyers, accountants etc) to develop
technology solutions to meet the needs of prospective clients, in particular smaller
entities for whom the building of a proprietary system is not justified or within their
means.
The evolution of supported common schema also serves to increase transparency for
all market participants and supports the development of new functionality such as
smart contracts and negotiation (which would further reduce the legal cost of doing
business). In this context a strong rules layer compliments the emergence of
Blockchain and similar initiatives that (in addition to addressing contractual certainty
and settlement risk), also help address data validation type issues that continue to be
problematic.
Ultimately, the reduction of costs and increase in transparency would benefit not only
enterprise but also citizens who are generally the ultimate end clients of financial
entities. It would also assist in the EU’s objectives in achieving Capital Markets and
Banking Union.
21
Proceedings of the 1st Workshop on Technologies for Regulatory Compliance
5. Thoughts on Functionality
While it is premature to speculate in detail about the technical approach, we set out
below some thoughts on the functionality in the context of how users might interact
with the knowledgebase.
As a starting point, the knowledgebase could provide a means for entities to quickly
determine whether they were in scope of EMIR and/or any third country regimes.
Having established they were in scope, the knowledgebase could (based on
submission of the relevant facts) determine which regime or regimes applied to a
particular cross-border transaction. For example, it may be that compliance with the
third country rules was permitted (in whole or in part) as there was an equivalence
determination for the relevant third country.
The next logical step would be to determine exactly what requirements applied. Again
this would be based on submission of the relevant supporting facts (which may
include data about existing OTC derivative positions and entity static data).
Existing (non-semantic) knowledgebases normally rely on a network of legal experts
in relevant jurisdictions to produce a narrative of the relevant laws in their
jurisdiction. The creation process is manual, time-consuming and cost intensive.
Regular review and updates also require manual input. Therefore, for any
knowledgebase to remain up to date requires the continued support of a sponsor with
a vested interest.
For a knowledgebase to survive after the initial funding, thought should be given to
putting in place a sustainable support structure. This is likely to involve collaboration
with professionals, industry bodies and product providers.
On the technical aspect of updates, as many laws are now published in XML, there
may be scope to automate the process of identifying when updates are required.
A powerful query functionality and API are likely to be of high importance. In
financial trading, time is typically of the essence. Therefore, for any given transaction,
it would be useful for trading firms to be able to machine automate the pre-trade
analysis and post trade reporting. Therefore, a strong API through which a trading
system can query the knowledge base would be of great utility.
Similarly, a strong query engine and API would facilitate a high degree of
interoperability with other internal systems (such as Risk, Finance, Treasury, Control
Functions etc) as well as providing the ability for senior management to benefit from
enhanced analytics.
As for the shared schema, an API would also create a foundation on which
commercial solution providers may build solutions.
22
Proceedings of the 1st Workshop on Technologies for Regulatory Compliance
6. Scope
Setting the correct scope for such a use case will be critical. Scope and utility are
positively correlated, but the scope must be sufficiently narrow to be within the reach
of the Lynx resources. However, to have utility for enterprises, it should address a
meaningful segment of required functionality.
We believe there is potential to leverage resources external to Lynx to ensure a good
balance between scope and utility. And we believe this approach may be a means of
smoothing the process towards self-sufficiency after the Lynx Project. We would be
happy to discuss further.
7. Conclusion
We believe that a knowledgebase utility would have many advantages for EU
companies. For the reasons outlines above, we believe it would provide reduce the
cost of compliance, increase transparency and efficiency, provide greater value for
participants, their clients and citizens alike. It would provide efficiencies across the
industry and give life to new products and business models and would also support
the EU’s objectives in terms of Capital Markets and Banking Union, all of which
would contribute to the EU economy.
References
[1] Regulation No 648/2012 of the European Parliament and of the Council of 4 July
2012 on OTC derivatives, central counterparties and trade repositories.
23