5 keys to success.
It seems like everyone’s jumping on the RegTech bandwagon, it’s been referred to as “the new FinTech”, “the sexiest part of fintech”, a book is being written on it and even regulators such as the FCA are saying that they “want to encourage RegTech adoption”.
At the same time, it has never been so easy for a company to set up and start creating software. Sprinkle in a sexy website, some slick marketing and a sales team that says the product can do everything and hey presto: an instant recipe for disaster.
Here are some of the key factors we believe are vital in deciding if a vendor is “doing RegTech right”:
1) An accredited source providing legal information and interpretation
Some regulation is relatively simple and easily understandable. The vast majority, however, is not. Some regulation changes infrequently, but again the majority changes very rapidly. Hence why we have Star Trek like regulation numbering: UCITS VI, CRD IV, Basel III, MiFID II etc.
Monitoring for changes and interpreting regulation requires deep understanding and multi-year experience. It cannot be learned overnight.
2) A team that combines both regulatory AND technical expertise
As mentioned above, it’s relatively easy to start building software these days and it’s also quite straightforward to find people with a good understanding of regulation. What’s truly difficult is to marry the two together into a close-knit team that can deliver regulatory change in the form of algorithms in a matter of hours rather than months.
3) A bomb-proof update process
Obviously, you need to have confidence that nothing is going to fall through the cracks. A single missed update could easily lead to considerable sanctions.
Here at FundApps we’ve been fine-tuning our process for over 6 years now and have settled upon a workflow which allows for as few errors as possible:
● A regulatory update email is sent to us by our Legal Information Provider (aosphere).
● An issue is automatically created in our work tracking system (Clubhouse).
● The issue is assigned to a member of the content team who is on triage duty.
● They decide if action is required. If not, then they must add a comment as to why not and a second person must also agree. The issue is then archived.
● If work is required, then a due date and a team member is assigned.
● Once the person is finished it is assigned to a second person who is responsible for reviewing the changes, the tests and the test results.
Automated tools constantly monitor the pipeline, escalating relevant issues which makes it impossible for them to fall through the cracks.
4) A focus on testing that is borderline paranoid
Some questions to ask a vendor:
● When a new rule is created, is it reviewed by someone else?
● Is the new rule tested? With a single scenario or multiple scenarios?
● If so, is it manually or automated?
At FundApps:
● Every rule has multiple tests. Complexity of the rule drives how many, this is especially relevant for rules which trigger over periods of time, e.g. 13F.
● We’ve built up a suite of over 1000 rule tests.
● Every time we make even a single line code change to our engine, every single rule test is run again to ensure everything is still working as expected.
● In an almost Inception-like move, we’ve also introduced tests which check our test coverage! E.g. If a new rule is created without a test, our test coverage test will alert.
For more detail we’ve written a blog-post on how we test.
5) Cloud-based with a battle-hardened team keeping it ultra-secure and available
We don’t believe you can do RegTech without the cloud. Regulations arise too quickly and unpredictably for a vendor to be able to push updates to an on-premise solution. Imagine a new regulation requires the software vendor to update rules and their source code: how are they going to get a new version of their software installed at the client?
Financial services’ IT teams are famously understaffed and can sometimes take weeks or even months to install new versions of software. During that time an institution will be non-compliant and risk sanctions.
That said, doing Cloud “right” requires people who know really what they’re doing. The internet is littered with examples of it being done wrong. Things you should be asking:
● To see their BCP (Business Continuity Plans), their DR (Disaster Recovery) documents. If a server falls over, will somebody have to be woken up, travel to a server room and reboot a PC or is it all automated?
● Who can access your data? Is it every Tom, Dick and Harry at the vendor or just those with appropriate permissions?
● Do they provide SSO (Single sign-on) and IP restrictions?
Cloud = community, commentary etc. We stand by a firm commitment to doing things the right way, we don’t sell vapourware, we care about customer satisfaction, data security, and robust, accurate software and work hard to make sure we provide the best solution possible.
All this comes unfortunately at a cost, so if a vendor quotes you a price that appears too good to be true, well… perhaps it’s time to start asking them some of the questions above and yourself whether it’s worth it.
If you'd like to automate your compliance processes and join a growing community of compliance experts then get in touch!
