Getting the most out of your automated compliance software means getting the most out of this highly specialized translation
We know that an enterprise financial firm's code of ethics lays out the specific do's and don'ts of employee investing. The kinds of securities they're allowed to invest in and the kinds they're not. When they're allowed to trade certain securities. The securities they can never trade. Different thresholds for different lines of business. Every firm has a code of ethics, spelled out in writing somewhere, but the trick has always been ensuring that code is adhered to.
Previously, ensuring compliance was a manual process: the hands-on management and monitoring of a paper trail by a team of compliance officers. With the advent of modern compliance software much of that manual work has been eliminated, primarily through the automation of a firm's code of ethics. What this means is translating that code of ethics, expressed as written policies, into the software code that powers the decision-making algorithms at the heart of the automated process.
For a compliance software company, this is what's known as an implementation, and there's typically a dedicated team of experienced business analysts who handle it. Here's an overview of how this all-important translation happens, and steps you can take to help it along and maximize the end result.
"The client's code of ethics gives us their business requirements, and that's really our starting point," says Kelsey Amar, Associate Director and Head of US Professional Services for StarCompliance. "The business requirements tell us what objective the firm is trying to achieve with a particular rule, and then we configure the system to achieve that objective."
For example, a company's code of ethics might say employees are not permitted to trade at the same time as their clients. The business requirement here is, if your client is trading in a security you can't be trading in that security. So an implementation team takes that information and works out what the system should do with it. The end product, the decision whether or not to allow a specific type of employee activity, should mimic the decision a living, breathing compliance officer would have made given the same information.
This specialized translation is where a compliance software company's expertise comes in. A firm like Star knows what best practices are, with business analysts often having a better grasp of what the client is trying to achieve, in terms of system output, than the client itself. "We tell them, here's what your code of ethics says and here's what we see as best practices for this area. And then we have them test that. What we really try and avoid is going into a client and just dumping the big box of system building blocks on the table and asking them what they want. That can be overwhelming."
THE DEVILS IN THE DETAILS
Of course, this is all very straightforward in theory but not necessarily in practice. Making a successful translation from written code into software code means more than flipping through a rulebook and tidily turning the contents line by line into algorithms. The written code is unlikely to get down to the level of granularity necessary for the system's rules engine to do its job effectively. "The rules exist in the code of ethics," says Amar. "How granularly they're defined is where we come in. We need to get to a certain level of detail."
An example of this is the 30-day holding rule. A standard code of ethics might say a client has to hold a security for 30 days, or can't recognize a profit for 30 days. But how is that written rule processed? That's the part that's not in writing: the part the implementation team needs to get its head around to build the rules engine. And the way the team gets there is to talk directly with compliance officers and ask refining questions. "We have to involve their compliance team in the build-out," says Amar. "We can't just have a firm hand us its code of ethics and say 'build the system.' 80% of any rule is the business requirement and the other 20% is workflow. That is, what happens next? Does it go to a form? What does the form look like? We need access to compliance for that."
But even with unlimited access to compliance and a clearly written code of ethics, complexities can arise. One of the most common results comes from having different codes of ethics coexisting in the same organization. Most companies have a single code, perhaps with carve-outs and exceptions for certain groups. This makes for a relatively straightforward build. But sometimes different lines of business can mean entirely different codes of ethics, split out for each line. "We've built compliance platforms with as many as nine codes," says Amar. "It's complex, but doable. But what I'm increasingly seeing is firms centralizing their codes of ethics: getting all their lines of business onto one code."
There are other things an enterprise financial firm can do to prepare for a compliance software implementation, some so obvious they're actually very easy to overlook. "You'd be surprised at the number of implementations," says Amar, "where we go in and say, 'your code of ethics says such and such, and here's how that translates into the system.' And they stop us and say, 'wait, we don't know how that should work. We have to think about that.' Know what your code says and give some thought to how you want to build it into the workflow."
And for those clients transitioning from a paper system, keep an open mind as to how software can get you to your desired end result. Again, Amar: "Clients often come to us and say 'this is our business requirement and this is how we want the system to work.' But sometimes their idea is really roundabout, and because we've done hundreds of these implementations we can say, 'here's a better way to get you from Point A to Point Z. Let's get you out of this paper mindset and let the program do the work. And then you can focus on compliance.'"