One of the most surprising facts I have encountered in our little niche market of financial services onboarding and certification, is just how much attitudes vary towards it.
Certification is the "driving test" that counterparties are required to perform to demonstrate compliance with a trading or market data interface. In a world of continually changing software and algorithms, how often should counterparties be put through their paces?
Some exchanges don't require much formal certification at all (e.g. Deutsche Boerse), some require certification only upon initial application (e.g. NASDAQ), and some demand regular re-certification (e.g. London Stock Exchange who ask all members to re-certify twice per year). Brokers typically bend over backwards to actively avoid re-certifying their customers, as anyone who has ever seen algos labeled CUSTOM1, CUSTOM2 and CUSTOM3 will readily attest.
This general lack of re-certification seems to be completely off the radar of most compliance teams and regulators - a seemingly (large) blind spot given the continual tidal wave of regulations requiring increased testing and monitoring of electronic trading systems.
If you accept the premise that more frequent certification can only reduce the likelihood of things going wrong (it's very hard to argue that it would increase risk), why don't firms certify more? The answer is very obvious - it takes too much time and effort to set-up, schedule and administer.
What if there was a better way? Enter the idea of "continual certification" - a process which runs production data through certification to see if people are still compliant. After all, if you demonstrate you can enter, amend and delete orders in production every day, why do you need to demonstrate it again in a special time slot?
A good real-world analogy for continual certification is "Pay How You Drive" (PHYD) car insurance. Newly-qualified drivers typically face steep premiums because - as a profile group - they are seen as more risky than experienced drivers. Under a PHYD scheme, however, new drivers can install a telematics box in their car that tracks and reports on their real-world driving (i.e. production), effectively subjecting them to a continual driving test that the insurer can review and adjusting their risk and premiums accordingly.
Not only would continual certification check that counterparties are correctly interfacing with your application, but it can also highlight areas where clients are doing things that they are not certified to do (blind spot number 2).
For the sake of minimising initial certification effort, it's very common to remove certain maneuvers from the certification pack. For example if my algo box can only send out limit orders, why do I need to demonstrate any other order type? It makes perfect sense, but where does that information go, and how is it actually enforced in production? We know that some brokers and venues do have controls and procedures in place, but it is far from universal and the job of reviewing logs to check clients are still behaving the same way is... well a lot of effort. How would you feel if you had a car accident with someone who was only qualified to drive a motorbike?
When done correctly, not only does continual certification reduce overall risk in the trading ecosystem but it also yields new business intelligence insights into exactly how people are interacting on your API, so it ticks the big data buzzword box too.
Continual certification has the potential to significantly reduce risk while minimizing the administrative burden of recertification (especially when coupled with a self-certification portal giving clients a view into their own activity), which is why I believe it will become a major trend in the next 3 years.