Close

The right insights, right now

Access the latest news, analysis and trends impacting your business.

Explore our insights by topic:

About Broadridge

Navigating The Perfect Storm of Regulatory Changes

We discuss with Regulation Asia on how firms can better prepare for the upcoming regulatory landscape.

Latest developments around 10C-1

Video Transcript

Speaker 1 [00:00:04] So 21 is relatively new. Right. It's it's it's something that's kind of only really been established or been presented to the market in the last six months or so. It's it's an S.E.C. regulation and it's to do with securities lending. So we already have securities lending regulation by ESMA for SFR, which was came into force a couple of years ago dealing with securities lending repos, stock bar, etc., etc.. It's an end of day regime and a very sorry obligation looking at all that data kind of broadly aligned with G20, but not not obviously not at sea. Now 20 dash one is a similar beast, but for US markets currently anything you do on us is not relevant to Europe for ESMA. So this is a broadly similar regulation. It has some differences. It's not as complicated with a number of fields, but it also has some interesting points around it. It's single sided. Unlike SFR, it again, it's the first time that it's the first time that the US markets will have to get this data and present it to a regulator. In this format, at least the single sided nature of it is is very different to what most of G20 is in fact, or the US regimes tend to be. So North American regimes are only one party reports as opposed to both sides, so that that kind of reconciliation between the two parties is less important. But it also adds complexity in that, you know, you have to report your opponents, your counterparties data and make sure you have all that data in a considered fashion. So there's no control points around that. But what's also interesting is that it has a very tight SLA. So there are essentially three parts to Kensi dash one. One is the transactional data, which has to be done within 15 minutes. And there's a couple of end of day points around volumes and other things which we shall there's more detail about that necessary. But that 15 minute SLA is challenging because the regulations say that's from the point of booking. Okay. Which is very similar to the SLA as you have on CFTC. So the moment that it's booked, essentially captured, you have the clock starts ticking until you have to get it to the regulator. Now, however, the industry considers booking to be at the point of settlement under the as your agreement with MSL. So there's already a discrepancy between when the industry thinks they're ready to kind of populate that data or publish that data and when the regulator wants it. So that's going to be a challenge. How is that going to work? Does that mean there's differences in booking models? When do you when do you have the veracity of those points? If you don't have them in 15 minutes, what are you going to do? So there's there's already debate and consultation about what those delays mean. Another very interesting point about Tennessee Dash one is that they have different UTR requirements, so utilize unique transaction identifier. It's a it's a global standard that is actually being harmonized and even more standardized. By keeping my ASCO and technical standards published about who generates this, how you get this information, how you share it. But for tenancy dash one, that's still has to be generated by FINRA and they have different criteria to what SFR does. So if you are in a situation where for SFR, you have a, you know, a bilateral agreement to say party A will always generate duties when we are trading. That may not be how FINRA said so when you have a global standard which immediately is in does not correlate with a tenancy, that's one standard. Again, there's questions about that. How is that going to work? Will we need separate bilateral agreements to be able to handle that, that difference from the global standard that that's forthcoming?

Exploring the changing regulatory landscape in APAC

Video Transcript

Speaker 1 [00:00:05] So. So again this is the UTC point is particularly relevant here because what's happening for the Isaac markets sorry, the API markets as well as in Europe is as we just kind of talked about, an adoption of global standard. So there are a few things that are being driven. There is standardization of UTI as in how can we make this a identify which is meaningful in aggregate, one can aggregate upon that same for identifiers and same for number of elements within within the actual reports that you're sending. So the change that we see in API is driven largely aligned with when we expect these global global standards to come into play. And as we said, these are standards to allow regulators to aggregate globally. All these things are about simplification of of generating equivalency through standardization between all these different regulations. And many, many years ago it was mooted that they would all be equivalent anyway. But the reality of that is that they're not they all have different nuances, different exceptions, different understandings of product and lifecycle, etc.. So we see all these coming into play across the APAC region, currently settled on like 23. However, there are issues in that the exact location may not be ready. So we whilst we expect 23, we don't know this 23 could easily be 24. Regardless, all of these things are set up happening at the same time. So that kind of leads us into a place where, you know, we have perhaps a perfect storm of a number of regulations, all being mandated for change at the same time. And this is also coupled alongside change. I mean, a revision were made is 3.0, if you will, in Europe and FCA as well as ESMA and FCA. All very well becoming more and more diverse had not a lot of not as much equivalency there as they used to be. So these are all pushing these old points of change that regulators are using to be able to look at what they need. We understand their data. Do we need different validation, all the data points we want to capture. So it and it's all happening at the same time. So, you know, with that in mind, you know. With not really understanding the precision of when this is happening. It's difficult for the market to really understand what they need to do to be able to get into place for all these things to happen.

The advantage of mutualization

Video Transcript

Speaker 1 [00:00:03] One of the benefits of of how? How we do our reporting products. We have a broad, which is that it's a community of users. So we have you know, we have well over 20 customers in G20 alone, as well as many more outside of of those regulations. But we very much operate as a community of knowledge. There's a mutualization benefit that comes from being part of this community. So when we look at rank change, you know, how does that what's that look like for us? It's tends to start obviously with our SMEs and our analysts looking at what that change means. And then we run working groups with our with our community groups to look at all that information and they feed back to us and we feed back to them. So we have we already have a mutualization of interpretation. And similarly, you know, post that interpretation, we have a mutualization of benefit. So if if a customer has requirements or product enhancements, that will propagate through to all of our community. So we in a fortunate place that we can we can take best practice from any number of firms who are part of that community and bring it all to the fore to enable the most efficient and most, you know, complete reporting that we can do. Now, it's you know, there were other you know, one of the natural benefits of that is if we look at what we do as far as our usability and we've talked about we've talked about flexibility with regard to how how you can switch in and switch out connectors and what the harmonization model of Pair X brings to that. And we talked a little bit now about community and how, you know, having a holistic approach across a number of of different customers allows us to kind of drive best practice within how we report. But there's also there's also kind of operability as well. So what does that mean as far as how do how can we make our software more flexible to the actual user? So if we if I go way back at the beginning when we talked about was an emissions for CFTC rewrite where you have the seven business day perspective to be able to to fix all of your all of your exceptions. So we've worked very hard with our community to kind of look at what that operational model looks like from all the different firms and how can we best represent that within our dashboard, within our user interface. So when we build that towards a kind of day in the life process, where what does a user need to do on a certain what's the first thing they're going to do in the day? They need to check their acceptance. So how do we bring those to the force that we've designed? You know, we have an exception matrix which is specific to can be subdivided slice and dice across all of the machines you have, which brings all those important those first most primary items you need to deal with right at the front of the dashboard.

Progress on ISO2022 standards

Video Transcript

Speaker 1 [00:00:04] So let's start with let's start with the CD because it kind of lends itself clinical data elements that lends itself well towards the ISO to 22 standard. The critical elements again, are similar to the similar to what is trying to be achieved. Utilizing API is about identifying points within that regulatory message that are well, hey, critical but be also common a commonality between all these regulations. So if you understand what those common points are when it comes to saying, let me look at my let me look at what is my market doing in this way, in this regulation or doing in this or in this within this regime or territory or or region and globally. How can we aggregate this all together? This is the common driver for all of these global globalization standards, global standards. So but alongside that, CDS is less of a challenge because these are it's just looking at how do we how do we knit together the regulations, where are they similar and where they differ, as I say to the 22, is a bit of a bit more of a marked change as far as the technicalities of reporting. So at the moment, each TR has their own format. They expect messages and perhaps a number of different formats and it may be submitting by CSP, may be it may be in female financial policy markup language, it may be in a bespoke format or in actually for for if you are already in ISO two W 22 as a standard. But even then that I started about 22 for SFR has metadata around it, so it isn't necessarily the same. And we also use it for MiFID two for ARM reporting, but it isn't necessarily the same. Want to ask if I need these extra fills? It's expressed slightly differently. It's it's all a bit it's all just a little bit varied. So the point of bringing this standard to four is that, you know, it allows firms to have it allows the regulator to have a more consistent picture. There is a movement to have less transformation between what you report to your trade repository and what is the regulator. They want to clear a path, a shorter lineage of data, so hence the use of this standard. Now, the challenge it presents is that. These are likely to be staggered. We talked about a perfect storm, but it's likely to be a staggered approach regardless close to each other. So what happens if if your mass is on ISO 1222 but your exec is still on perhaps a email via DCC? How do you how do you know you have you have a point with this particular trade? It has to be expressed in this language and in this language and what this model various different formats and that's challenging. What? It's a challenge in especially if you're perhaps more of a kind of evolved perhaps in house solution where you're looking at these individual stages. You know, all this was built up over the last ten years and various, you know, should go lives. But now you're going to have to unpick all that and say, how do I look at this holistically? How do I look at my data and say this exists in the bank in a harmonized format as it needs to be with the regulators?

Harmonization

Video Transcript

Speaker 1 [00:00:03] The focus for us is, as it has been for a long time, is again on harmonization. So obviously, we've talked about how the globalization of standards. Well, we we have always maintained a harmonized data model anyway. We have we have available good practice. It's all about exchange of data and commonality in a similar fashion to what we've been talking about, and we've been using that for a number of years. So our model within our reporting flow has commonality with all of our other products. So we can we can easily understand and interchange data between our regional products, but also between regulators and any other consumer of that data. And it has that standard. The reason we made this decision way back in 2000, 2012, when we looked at reporting specifically, is that it allows that data to be reused. So whether we are receiving data from from affirmation or through clearing processes or confirmation flows or any other system for a customer or internally, we have a kind of we have that harmonized standard view of what that means. We can interchange very quickly between all these systems. So we use that model naturally to look at what we're doing as far as data to TR per per regulation, and it brings a number of benefits, which is why then harmonizing generally in that we are able to then very quickly pivot data to any point. So there's been a lot of change in within MiFID and with SFR lately where APIs and arms are exiting the market as a service. So you may have been reporting to an API for a number of years, as is the case of one of our customers. That API for me for two is stepping out of the business. We need to get that data to someone else pretty, pretty quickly. So for us, because of the work, the effort we do through PR X, it's a pretty straightforward process. It's weeks, not months. It's it's a simply a matter of I mean, it's simply a matter of shutting things down, switching a switch to say send this data here rather than there having it about half. Again, that's oversimplistic, but that is the architecture behind what we do. So the kind of the onus then falls on the customer is really about validating and and testing to make sure that you're happy and you've done your diligence on how this is going to report. You know, the upshot will be end to end picture. Your source stays the same, publication stays the same, harmonization stays the same. We just swapping over connectors, and we can do that because of the standard model we have in the middle of this X model.

Let’s talk about what’s next for you

Our representatives and specialists are ready with the solutions you need to advance your business.

Want to speak with a sales representative?

Table Heading
+1 800 353 0103North America
+442075513000EMEA
+65 6438 1144APAC

Thank you.

Your sales rep submission has been received. One of our sales representatives will contact you soon.

Want to speak with a sales representative?

Table Heading
+1 800 353 0103North America
+442075513000EMEA
+65 6438 1144APAC