Documenting your Bank Secrecy Act (BSA) compliance program is a regulatory requirement. It is also a monster of a task. Such documentation is frequently done in a manual format. While the BSA provides a few guidelines, it does not give you a detailed road map for this task. Many organizations have documentation guidelines, policies and procedures. Too often these official documentation policies result in an explosion of section designations resembling National Security Agency encryption charts, bug type (really small lettering), overdone punctuation and enough abbreviated Latin phrases to stymie Cicero. After all, complexity equals comprehensiveness and quality. Well, maybe not.
Due to the requirements and variety of organization documentation guidelines and the wide array of hard copy and digital formats, it would be difficult to provide detailed advice as how to best construct or update any one manual. However, there are a few basic tips that will help make your program documentation a manageable and ultimately very useful tool.
Regardless of the size of the manual, it should be written and organized to minimize the intimidation factor. This is primarily done through effective navigation tools, limited use of jargon and acronyms, short manageable segments and a logical flow so that both strategic and tactical sequences flow in order.
Graphics are great explanatory tools, but they can also be sources of confusion and frustration. They are excellent when used for explaining checklists and step-by-step instructions. They are also great tools for depicting decision processes. They need to be accurate, visually attractive, uncomplicated and have the ability to stand on their own. They must also not contradict the written information (yes, that happens more often than one would think. The most common occurrence is when a process is updated in the text but not in the graphic and vice versa). Here are some clues that graphics could be improved: there is more space devoted to words than to the graphic itself; one has to squint or get a magnifying glass to see the graphic; and the graphic is not a viable set of instructions that is useful when hung on an office wall.
The manual should have an owner, preferably the most senior compliance professional. Note that the recommendation states compliance professional not compliance officer, because many large organization have executives who are excellent executives, but perhaps not the most experienced or knowledgeable compliance professionals. The owner of the manual must be able to understand, or at least be conversant, in all aspects of the document.
The manual owner should also dictate the content, organization and formatting of the various sections. While there will be multiple contributions by various department heads, subject- matter experts and executives, it is very important that the manual does not become a loose collection of documents. It’s a cliché, but a valid one, that documents created by committees are usually confusing at best, useless at worst.
Avoid overly technical material. The document is a program manual, not a programmer’s guide. While it is important to detail the technical tools used in your program, including the source code and technical specs for server configuration is unnecessary. Leave that documentation to your Information Technology Group.
Keep the body content to the information needed to understand the program’s required tasks and the detailed instructions as to how to complete those tasks. History, legal precedents, technical information and tangential policies and procedures should be in the appendices. The owner might also want to consider what really needs to be in the appendices. Remember, this is program manual, not an AML/BSA resource center. If the backup information is unique to your program, it merits inclusion. If not, make it a reference or digital link. Auditors do not judge program documentation on weight and volume or terabytes.
Here are a couple of suggestions not related directly to the actual document. The manual owner should have a backup owner. The backup owner should be kept aware of all modifications and additions to the document. The backup owner should also know exactly where the original manual is stored and how to access it. If the senior compliance officer hits the lottery jackpot and moves to Bora Bora, somebody has to seamlessly pick up the management of the program. Finally, there needs to be close attention paid to version control. As many manuals still exist in both hard copy and soft copy formats, it is imperative to ensure that once a change has been made in the parent document all modifications are reflected in all existing copies. To make this a manageable task one might want to consider having only three copies of the manual: the original under direct control of the owner, one printed version to meet requirements and look impressive on a bookshelf and finally a digital version that takes full advantage of the best possible online access, navigation and search functionality.
Even with all these considerations, creating, maintaining and controlling a program manual is one of the least pleasant tasks for any compliance program manager. It is a monster, no doubt. However, if you keep it under control, secured, prevent over breeding, and see to regular care and feeding it can at least be a useful monster.
Have a compliance communication issue you want to address, or perhaps a best practice or war story of your own that you’d like to share with your fellow compliance professionals? Send it in to stories@compliancecomm.com. Our goal is to help everyone become better communicators. We’d love to have you contribute to this effort.
This article is very interesting