Last year, we announced the launch of a new feature: Room-In-A-Name (RIAN), part of our Shareholding Disclosure Service.
We wanted to post an update and provide some insight into the complex problems we had to solve whilst developing this API report (spoiler alert! We now cover EU TDA Rules, US Sections 13 & 16 and Short Selling EU rules).
In addition, we thought it would be worth talking about how and why our clients choose to use RIAN - we think those reasons are likely relevant to many financial institutions and stem from common industry problems and needs, e.g. automating complex tasks that rely on manual methods (often involving spreadsheets), which can pose a major yet often underestimated risk; and gaining new insight, which firms previously did not have the resources to achieve.
Recap: what is it?
Room-In-A-Name calculates how much can be traded (“Room”) in an issuer (“Name”) before reaching the next reportable threshold. This calculation is run every time our clients automatically upload their position files.
The data can be extracted via an API, giving clients the flexibility to automate the daily ingestion of this data into a system of their choice.
How can it be used?
There are numerous ways in which our clients are using the information provided by RIAN:
‘Stealth mode’ - know exactly how much room there is to trade before having to disclose, preventing our clients from having to reveal their hand too early to the market.
Legal cost savings and investing in new jurisdictions - for investors who previously avoided investing in jurisdictions that they were not familiar with. Instead of paying for counsel or dedicating firm resources to research this, RIAN compliments the Shareholding Disclosure service and helps clients understand how many shares can be traded before a disclosure is required. This in turn allows our clients to maximise the firm’s resources and focus on core competencies.
Planning and resourcing for upcoming disclosures - know how much can be traded before reaching the next disclosure threshold. This allows our clients to plan ahead to ensure they have both the resources and understanding required to file correctly and on time.
Snippets from the Development Journey
Developing RIAN was a hard problem to solve. It required us to develop new calculations for all jurisdictions that we support. Managing this level of complexity and keeping all relevant details in mind was hard to do!
Our engineers certainly made good use of the interactive whiteboard whilst solving the complex problems they faced when working out how to calculate the values to be displayed in the API output.
Below shows how pattern matching was used to build the expressions used in the RIAN calculations based on those used in the rules: 
And this is how we handle Major Poland - a rule with complex alert expressions:
And once our developers had finished doodling on the TV, they had to then get down to the serious business of development!
Joking aside, hopefully, this gives some insight into both the complexities and challenges involved when determining the amount that can be traded prior to hitting the next threshold, as well as the value that can be derived from having such information. It’s clear to see why many of our clients are eager to get their hands on this data, ditch the spreadsheets and leave the complex calculations to us!
