Due Diligence In The Compliance World
Vendor selection is both an art and a science. There is data to collect, metrics to digest, testimonials to review, and recommendations to consider. Beyond the features, functionality, design, and overall look and feel of the software, a CIO has to consider factors such as implementation hurdles, acceptance challenges, and data migration.
One thing that frequently gets left out of the equation is Compliance due diligence. Depending on the regulatory scheme under which a company operates, the role of Compliance in the due diligence process may be relatively minor, or it may be almost as substantial as the other diligence described above.
The financial services world is one example where Compliance has a significant due diligence requirement. Rule 206(4) the Investment Advisor Act of 1940 requires a Registered Investment Advisor (RIA) to ensure that the policies and procedures of their third party vendors (and sub-vendors) meet the standards set by the RIA itself. This rule is rather far reaching and it puts the RIA (and usually the Compliance department) in the position of having to conduct a due diligence process separate from the normal IT process.
This is particularly difficult when Compliance is brought late in the game. It is not uncommon for IT departments to be presented with a business challenge and spec out the issue, identify potential solutions, do appropriate hardware/software analyses, and frequently even obtain trial versions of software prior to mentioning it to anyone outside of either IT or the requestor.
When Compliance is brought in at that late stage, a plethora of new challenges arise. The requisite Compliance due diligence has to be conducted–usually in an abbreviated timeframe due to trial limitations and pressure from the requestors, certifications, audit protocols, new policies/procedures must all be drafted, and training must occur. All of those things assume that there isn’t an inherent fl aw or issue in the initial request that would run afoul of a law or regulatory rule that makes the request untenable in the first place.
One example that has the financial services industry abuzz currently is social media. As the world moves into a “let us Face(book) that Insta(gram) picture so that we can be all a(Twitter) about it while being in a room Linked(in) together” paradigm, neither the law nor regulatory agencies nor the courts have caught up to the information overload age. This poses challenges to Compliance personnel as they grapple with balancing what people want against what they realistically believe will be allowable to regulators.
There is a FINRA rule that requires that all communications between a firm and a client be recorded. FINRA is the organization that regulates certain financial services companies known as broker/dealers. Over the past few years, FINRA has “clarified” their rules on communications to explain what they do and do not consider communications for the purposes of the record retention rule. These clarifications include concepts like determining if a social media post is “static” or “dynamic,” “scripted” or “unscripted,” and “real-time” versus “non real-time.” Each of these determinations has an impact on whether– and how–communications need to be recorded, retained, and preapproved.
These FINRA rules are offset by what have been colloquially known as the “anti-Facebook statutes” where several states have created laws that prohibit (to one degree or another) employers from requiring that employees provide usernames and passwords to social media sites. While the original intent of these laws was to prohibit discrimination in hiring practices, the drafting of the laws was very broad, and there are larger implications. Some of the laws have exceptions for other legal or regulatory schemas (such as FINRA rules), while other laws do not.
The nuanced (and rather esoteric) rules described above are not something that comes up in the normal IT scoping process, and without knowing about them (and the countless other laws and rules), that simple request from a senior vice president to unblock access to the Linked Twitter Book Gram website has larger ramifications. Depending on the culture and risk/reward metrics at an individual firm, the approach to resolving these issues will be very different.
No matter the corporate culture, however, there is a conversation to be had with Compliance, and the sooner into the process the better for everyone. Depending on the request, alternative approaches might be found, a more subtle solution to the business problem might be reached, the request might be withdrawn, or the green light may be given and have things proceed. The end result is that the request is addressed and fewer cycles are spent on potential solutions that won’t work for the business. Developing that early stage process of approaching Compliance can also help you pull the plug on the CEO’s pet project of the week–having two voices in opposition is better than one.
One thing I would like to point out about Compliance personnel–by far and large we are ‘not’ technology savants. My background is not the norm, and most Compliance officers typically have a purely legal or business background. That means that the role of the IT department in explaining what a project will actually do, what the potential risks are, and what the rewards are is paramount. Go easy on us–we spend a LOT of time reading legal trivia and a lot less time doing fun things like configuring DHCP servers to only service specified MAC addresses.
In summary, Compliance can be a pain in the neck for everyone. However, our goal isn’t to stifle creativity or hinder IT from doing their jobs. We want to make sure that the firm– any firm–is doing the best job it can while not getting into trouble down the road. The sooner in the project life cycle that Compliance is brought in, the less time is spent going down roads that lead nowhere, and the faster we can all move on to benchmarking our next potential purchases.