Regulatory Arbitrage: For IT Professionals, Too?

Actimize FMC Product Team, Financial Markets Compliance

Arbitrage is a word most IT professionals don’t tend to use. In fact, it’s a word that has little meaning in IT circles and that most IT professionals probably don’t use at all in their day-to-day discourse. On the other hand, to capital markets-related professionals, the word has significant importance and meaning.

I got to thinking about this and recalled Susannah Hammond’s excellent article entitled “Ten Things Compliance Officers Need To Do In 2013.” Her article’s list of 10 compliance-related guidelines forces anyone with an IT compliance background to consider the ramifications and relevance of #6 on her list, “Regulatory Arbitrage.” In calling out this topic, she highlights two key items.

First, she emphasizes the need for compliance officers to track the various attempts at creating “an internationally consistent approach to financial services regulation,” something which remains out of reach for a variety of reasons not worth getting into in this blog post that have to do with the Financial Stability Board (FSB) and theupcoming G-20 summit.

Second, she cites the need for compliance officers “to ensure that the potential for regulatory arbitrage is factored into risk assessments including in particular the evaluation of new business models or activities.” This second point is almost a warning to regulators by offering them a “shot-across-the-bow” indicating that if they are unable to elaborate on and to finalize these international agreements, financial services firms will be forced – from an economic point of view – to gradually migrate business to geographical regions that are lighter on regulations.

This all got me thinking about IT compliance, specifically some of the more well-known controls that most large enterprises contend with such as PCI-DSS and ISO 27002. And I got to thinking about the relative lack of coordination among these bodies that existed until recently. Most of these control sets were created in a vacuum and updated regularly by their respective steering committees and others for a defined need and focus. Yet we’re beginning to see a real attempt to coordinate these efforts. Three examples immediately come to mind.

  1. The HITRUST Common Security Framework (CSF) explicitly states that it “normalizes the security requirements of healthcare organizations (see slide 6 that references the HITECH Act, HIPAA, MA 201 CMR 17.00, PCI, COBIT, NIST, FTC and CMS).”
  2. Second, the BITS Standard Information Gathering (SIG) Questionnaire from Shared Assessments started approximately 8-9 years ago as an attempt by US financial services firms to make life easier on vendors and for broader vendor risk management; however, its recent updates map the controls to various well-known frameworks such as the Unified Compliance Framework (UCF). Moreover, there are those who think the SIG should be mapped or somehow broadly correlated to The Standard of Good Practice for Information Security, published by the Information Security Forum (ISF) that has more of a European bent.
  3. Finally, the relatively new Cloud Controls Matrix (CCM) from the Cloud Security Alliance (CSA) exists to bridge precisely these gaps: “The foundations of the Cloud Security Alliance Controls Matrix rest on its customized relationship to other industry-accepted security standards, regulations, and controls frameworks such as the ISO 27001/27002, ISACA COBIT, PCI, NIST, Jericho Forum and NERC CIP.”

Compliance officers responsible for capital markets-focused financial services firms and compliance officers responsible for “generic” IT compliance do and don’t share a lot in common. Both groups’ approach to compliance, to regulators, to internal audit teams, and to topics such as employee training and audit trails are all conceptually quite similar. Yet the organizations that define the standards and controls by which these professionals – and their employers – must abide actually handle things substantially differently due to who they are.

In the IT compliance and risk world, there is no formal governmental regulator with the power to snap fingers and make the various control sets play nicely together with one another. On the other hand, the financial services world is regulated primarily by government regulators (and SROs) and therefore does have more of a legal mandate to make regulations interact, translate, and otherwise inter-relate with one another across financial products, markets, and jurisdictional lines.

Comparing the way these two types of regulatory creatures can and cannot influence the broader need for consistency and predictability across regulatory regimes remains a fascinating topic worthy of further analysis and commentary. I would expect to see lots of developments and changes in this arena in the years ahead.

Speak to an Expert