5 minute read
The regulatory environment governing the financial and professional services industry is continually evolving with new regulations, modifications to current regulations, directives, and other requirements being issued on a regular basis.
Financial institutions are one of the most frequently attacked sectors in terms of cyberattacks, and regulations are means to make sure that businesses maintain a basic level of security by enforcement of the laws and rules in finance and the capital markets.
It spans through entire financial sector from investment banking to retail banking.
What is financial compliance?
Financial compliance is about making sure the regulation and enforcement of rules and laws exists within the financial services and capital market.
Its purpose is to safeguard the integrity and transparency of the financial markets while safeguarding consumers, investors, the economy, and society at large from systemic risk, market manipulation, and financial crime.
As regulators seek to keep an eye on everything from trading activity and accounting standards to tax evasion and money laundering, compliance systems have advanced through time and grown more complex.
Why is financial compliance important?
Financial compliance became a critical issue for regulators and other concerned parties following the 2008 Global Financial Crisis.
Appropriate financial compliance in 2008 could have prevented people from losing their homes, pensions, and retirement money, as well as lowered the recession's overall severity.
Financial compliance is also necessary to preserve public confidence in the banking industry and capital markets.
After the 2008 financial crisis, financial bodies started reassessing the ways to improve investor protection through law. This reassessment led to an increasing focus on improving the level of protection available to professional clients by introducing the compliances such as GDPR and MIFID II.
Financial services compliances
MIFID
The Markets in Financial Instruments Directive (MiFID) is a European regulation that unifies the regulatory disclosures necessary for financial institutions to do business in the European Union and improves market transparency throughout the European Union.
MiFID regulation went into effect in 2007, the financial sector generally viewed it as an unfinished undertaking that needed significant reform.
One major problem with the MiFID was that each member state was permitted to decide how to regulate relations with nations outside the European Union. Due to the simpler regulatory scrutiny, this meant that some businesses outside of the EU might have a competitive edge over businesses inside the union.
These changes were addressed in MiFID II, which became effective in January 2018.
MiFID II or MiFIR
The European Commission implemented MiFID II, an updated directive, in 2018. The updated directive was initially put forth in 2012 with the goal of regaining market confidence after the market meltdown of 2008.
MiFID II and MiFIR assured more equitable, secure, and effective markets. MiFID II expanded the rules to issuers of all securities, including debt securities, derivatives, and structured instruments, whereas MiFID was restricted to issuers of equity stocks.
The usage of dark pools and OTC trading was decreased as a result of the new rule, which increased transparency and reporting requirements for securities trades.
The improvement of requirements in several areas, such as on the responsibility of management bodies, inducements, information and reporting to clients, cross-selling, and the introduction of new requirements on product governance and independent investment advice strengthens the protection of investors.
Impact of Brexit
One of the major issues that came up during the preparation of MiFID II was how to handle business from third countries.
The Financial Conduct Authority, a regulatory body, claims that Mifid II will have some of its "rough edges sanded off" in post-Brexit Britain but that there is no desire to fully eliminate the EU's protection for investors under UK law (FCA).
The UK's MiFIR reporting requirements are therefore comparable to those of the EU, however there may be some circumstances in which companies must submit two reports to meet both EU and UK MiFIR reporting requirements.
MiFID II data architecture requirements
Market transparency standards have improved thanks to MiFID II.
Transaction reporting is now required on a T+1 basis for all financial instruments, with one significant difference: although MiFID I concentrated on 20 fields, MiFID II increased that number to 65.
Both buy-side and sell-side companies will experience difficulties as a result, and investment managers will face tremendous data management challenges.
The MiFID II data architecture standards involves every area, from reference databases and legal entity identities to trade order and execution management systems (OMS/EMS) (LEIs).
Companies are developing methods for collecting data from various sources. This is the only way to provide a comprehensive disclosure to both regulators and clients.
Use cases: Trade store
Challenges
The main goal of MiFID II is to improve trade reporting and trade transparency through data collection.
Although a large portion of the data that MiFID II requires you to collect may already be kept, there are still three hurdles to overcome:
- The need to store enormous amounts of data may seem like a straightforward challenge to solve, but the data is likely to originate from numerous silos and may be in different formats, such as voice vs. email.
- Trade data must be handled and stored in such a way that auditors can easily access it and understand it.
- Transactions must be accessible for immediate observation.
Solutions: Architecture
Source: MarkLogic
Datavid has a long history of helping financial services companies throughout the world overcome tough data challenges, like the ones such as those listed above.
The operational and transactional MarkLogic Enterprise NoSQL database platform has been implemented by leading investment banks to integrate, store, manage, and search their mission-critical data.
This experience has served as the foundation for our solution architecture for regulatory reporting.
#1 Data ingestion and optimisation
Multiple sources of information are consumed in their original format. Information is verified at the time of intake. Invalid or damaged information is still consumed, but exceptions are raised for a later in-place reconciliation.
This makes it possible to manage data holistically and guarantees that no data is lost.
We may opt to add metadata (materialise core attributes/complex attributes) in order to make improvements in this area. These could be very prevalent attributes or costly run-time attributes to calculate.
Resource Description Framework, or triples, which indicate relationships between "facts," is another format in which this metadata is kept. These details might be connected into an enterprise data model, or map (often referred to as an ontology).
These features offer complete lineage and provenance for enterprise class reports that are generated in real-time from a variety of source systems.
Additionally, despite changing data sources and shapes, the bi-temporal management of these trades and the related metadata enables a consistent view of the trade environment at any given time, supporting the governance process.
#2 Storage of data
Some materialised data, some metadata (RDF), and the original data are all present in the repository.
Consider this as a three-level system where I can optimise access to materialised attributes, ask queries of the original data, or give enterprise-wide reporting and e-discovery using the RDF meta-data.
#3 Reporting
The reusable reporting modules are an important element.
These libraries can be used once more to specify fields in fresh reports for fresh clients. The ability to adapt to changing regulatory requirements is provided by this.
#4 Monitoring
When information is ingested, reported, or re-reported, the system can easily trace when it was done so by looking at the transaction meta-data.
Frequently asked questions
