Many financial services organizations are well on their way to implementing a data management and reporting strategy to comply with the upcoming MiFID II requirements. For our procrastinator friends out there who perhaps haven’t read through all 196 pages of the regulation as it pertains to transaction reporting requirements, here’s what you need to know.
MiFID II requires more accurate and granular reporting on trading activities so regulators can reconstitute each key stage throughout the processing of each transaction to identify suspicious order behaviors (Article 50). This includes recording and reporting things including:
- HFT (High Frequency Trading) activities at 100 microsecond latency
- Algorithmic, but non-HFT activities at 1 millisecond latency
- Manual trading activities, over the phone or online, at a 1 second standard.
Investment firms also must synchronize their clocks to record the date and time of any reportable event to Coordinated Universal Time (UTC) at 100 microsecond level precision. (RTS 25).
Even if this is your first-time hearing of such requirements, it’s likely that as a next step, your teams should start to evaluate their legacy infrastructure’s ability (or lack thereof) to meet these stringent new reporting requirements.
Some architects who hear of the strict low-latency reporting requirements may have the impulse to leverage a NoSQL solution – which can be an option, if you’re also prepared to deal with the complexities of building logic into your applications to manage data consistency in the database (which also assumes your application developers are distributed systems engineers).
If that was the route you took, you had the right instinct – look for a high throughput, low latency, and highly available system. Why would you, now well down your path to a solution, ever reconsider your choice of database? Well if you haven’t run into issues yet, our experience says it’s very likely you soon will.
When it comes to managing regulations, ACID compliance should be short listed on your application requirements. It’s not enough to just be fast: the data must be accurate too. With an eventually-consistent NoSQL solution, you’ll have to wait until the data is in the same state on all servers – which can be particularly problematic for MiFID II, as it requires your real-time monitoring systems to generate alerts within five seconds of unanticipated trading activities.
Additionally, consider a situation where a transaction fails and the database considers the last read to be correct. That leaves you submitting a report on false information. I don’t know about you, but with my luck, I wouldn’t want to take that chance or pay that fine.
And yes, MiFID is just one regulatory requirement, but it’s widely understood that there will always be new regulations you will need to comply with. For some, this means more headaches and long hours spent re-architecting internal platforms to meet the ever-changing regulatory landscape – but a large multinational financial services customer of ours had a better idea.
They were able to create a decision-making platform similar to the one below:
When trade event data comes in, there are many decisions to be taken. To name a few:
- What is the asset class?
- What is the jurisdiction?
- Is this event reportable?
- What are the compliance specifications that are relevant to this event?
- What is the data format to transform/enrich the event data to?
In a traditional database, and in some cases of streaming engines married to a traditional database, the typical pattern is to store the data. Then, in batch mode, a complex query is issued to find the records that match different combinations of these questions, and is then processed in batches. The question is when the event data is streaming, why would you want to accrue batches of data to process these events?
At Volt Active Data, we have a different approach to address streaming data. When the data arrives, Volt Active Data processes the data as it arrives. Processing of event data within a stored procedure provides a construct within which all the above questions can be asked and answered. Based on the answer, an appropriate “export connector/formatter” is used to perform the data transformation to send to the appropriate recipient.
Because these processes are seamlessly integrated into Volt Active Data’s stored procedures and processed in real-time as data arrives, the data is always 100% consistent – which means there is no need to worry about building and managing complex logic to maintain data consistency at the application level. And that’s not even the best part! The system can be used for virtually any regulatory reporting, because reporting rules and templates can be easily adjusted without re-building the whole system. That’s a RegTech game-changer!
Even if you’re well on your way to implementing your MiFID II-compliant system, it may be worth asking: ‘Is there a better way to do this that will not only save me the burden of potential inconsistencies, but also save me an invaluable amount of time down the road when new regulations come out?’.
Disagree? I’d like to hear from you: What has been your approach and has it been successful?
