Writing a Policy

by Andy Zavoina, BOL Guru

Writing a policy can be confusing, whether it is your first or hundredth. "How long should it be, what is the required content and what is a good format?," are all pertinent questions to ask before you begin.

By definition, a policy is "a plan or course of action, as of a government, political party, or business, intended to influence and determine decisions, actions, and other matters". It is meant to be long-term guidance for the bank.

A policy is meant to standardize the approach your bank takes as it addresses a regulatory or business need. Different branches, departments and persons should be handling matters in the same way because you want the same results. If a customer has a problem or there is a regulatory requirement to be met, the issue is with the bank. It isn't with a branch, department, issue or person, and all similar issues should be handled similarly. This provides consistent treatment over the long term.

A policy should reflect what the bank does, not what it should do. A policy shouldn't be carefully crafted so as to meet a documentary need, but not adhered to in practice. I have heard before "that may be what the policy says, but we can't do that". Either the policy or the practice needs to change. And remember, the policy is the guidance from the board.

Policies don't have to be in written form in most cases. But the palest of inks is better than the sharpest of memories. Having a policy written ensures each person reading it gets the same message. Policies passed from person to person orally will become frayed and less effective. An auditor is more assured of what the policy is when it is written, than when they have to interview numerous persons carrying out an unwritten policy. Testing is easier and even if an unwritten policy is being followed, a continued high level of confidence is unlikely in today's changing environment.

A common question is what policies are required. This is a difficult question and what is "required" is not the same as "what is needed". Guidance "needs" exceed guidance "requirements". Your regulator will expect policies for those areas in which long-term guidance is preferred. This doesn't mean you need a policy for every regulatory requirement that exists. "Need" is based on your products, services, corporate culture and history. The OCC Corporate Licensing Manual has provided the following list of needed policies:
a. Lending
b. Funds Management, Investment Securities, And Interest Rate Risk
c. Fiduciary (Trust banks)
d. Capital
e. Internal/External audits
f. Insider Activities
g. Compliance
i. Compliance Program
ii. Branch Closing
iii. BSA (AML/EDD/CIP)
iv. Securities Transactions for Broker-Dealers
v. Board Supervision
vi. Disaster Recovery
vii. Privacy and Security

This list is not exhaustive. Only applicable items should be considered but those items will reach beyond minimum requirements. Remember that the purpose and intent of a policy is not to meet a regulatory requirement, but to provide guidance.

Obviously new requirements also arise over time, such as the requirement for a written information security policy/program which took effect July 1, 2001. Stay attuned to the changes in requirements.

A policy is a brief document stating a position. It basically says, "we will". It is a 15,000-foot view of what will be, and a procedure augments the policy. It is equally important and should be crafted well. The employee executing the policy uses the procedures for the actual "how to".

The policy is approved by the board and should have a long shelf life. The procedures have a shorter shelf life and are approved, in most cases, by senior management. (An exception is in the are of CIP. There, the rules specifically require the board to approve both the policy and the procedures.) These may be very detailed and act as a roadmap giving step-by-step directions to the user. Procedures may be very detailed if the bank desires, or they may act as finite guidance without specifying, for example, what CIF screens to review when opening a new account. Because of the increased detail, procedures need more flexibility and will typically be amended more frequently. This is why senior management should have approval of procedures.

Here are ten key steps for writing a policy.

1. Review the requirements of the subject matter the policy will be about and divide it into what are stated requirements and what you have some flexibility on. This will ensure you include everything that is necessary and that you tailor the other requirements to your needs. You do not want to write a policy that imposes more requirements than are needed. This only increases your regulatory burdens and your opportunity to err.
2. Include senior management, line managers and line personnel in your drafting process. The policy has to meet regulatory requirements. That is one of your main functions. But it also has to fit into the bank's strategic plan, infrastructure and be workable at all levels. Without interviewing these people and obtaining their input, you may be unaware of the complexities of putting the policy in place. You could be setting yourself up to fail without them.
3. Outline the regulatory requirements, using citations in your document. When a requirement changes, having the citations in your policy and procedures will make maintenance easier. It adds credibility to your document in the event a part is challenged and it will facilitate faster reference to the actual regulation. It can also act as a checklist to ensure all aspects were addressed as needed.
4. Name the policy so that it is an easy reference relative to the topic and subject matter. I have had examiners criticize an insider loan policy that I wrote. I exclaimed it was very detailed and they thought it was brief. What they reviewed was one section of the bank's loan policy. There was a separate "Insider Activities - Reg. O" policy, however, that they had not seen. It should have been cross-referenced and a plain title to the policy would also reduce confusion about the content.
5. Establish a standard format for your policies. Similar header and footer information should be used in all policies. Since these are technically from the board, they should appear as to be from the same author. A standard format will help users find information and allow a more efficient inventory of all your policies and procedures.
   
   The header should include the applicable bank, the subject and regulatory citation it applies to, the policy number for inventory control, the revision date, page numbers and consider adding the origination date of the policy so you will understand how long the issue has been addressed. Here is one example:
   
   XYZ NATIONAL BANK
   Subject : Flood Policy -12 CFR 22
   Policy Number : CP-100 Origination Date : 10-24-01
   Revision Date : 11-20-02 Page Number : 3
   
   The footer should have the documents file name and path so that the original document may be found on the author's computer when needed. This is easy to do with today's word processing programs and the font may be very small so as to not detract from the real content.
   
   
6. Policies should be separated to allow complete development of individual issues. This also requires less maintenance when the policy is updated and therefore reduces costs. Some bankers believed combining a Reg E policy with ACH and Internet Banking would be a good idea. But these have separate requirements and while having some commonalities, have more differences. Just reducing the size of the policy itself is a plus because it reduces the reading necessary to find an answer to a policy question.
   
   Some policies should be bundled, as they follow the same requirements. An example of this is your Bank Secrecy Act policy which should reference Anti-Money Laundering and the Customer Information Program.
   
   
7. The policy itself should be succinct. It expresses the board's commitment to the subject, assigns responsibility for the requirements, requires reporting on the progress and performance, as needed, and states the overall objective. It is not a lengthy document, as commitment need not be mired in details.
   
   
8. policy is not a regulation converted to easy to read English. This adds bulk without substance. These details are not needed for the board to provide its direction.
   
   
9. Focus on the spirit and intent of the requirements being addressed. Doing this will help ensure the direction is on target and it will make interpretations more consistent with what the requirement is supposed to accomplish. This is a key issue because the employees who implement the policy must know what it is meant to do.
   
   
10. "Staff" the policy by those senior managers, line managers and line personnel you interviewed in step two. Their input on the draft helps assure you it is workable and of buy-in when it has to be implemented.

    You may find policy templates (both free and at a cost) on numerous Web sites such as BankersOnline.com and Kirchman's. There are other vendors selling these as well. Any time you want to use another's policy, review it carefully. Requirements imposed upon them may differ based on their regulator and the board's desires. Certainly you must change the name. Yes, reviewers have seen this. The bank name wasn't changed and the policy was not updated and said, for example, "insert Reg. CC hold preference here".
    
    Your policy should be written such that you could explain it when being questioned on "60 Minutes" or from the witness box in front of 12 of your peers. This is a document that provides direction. That direction may be questioned at some point. Clarity is a requirement in a policy. They should be read in black and white, not gray.
    
    The original version appeared in the September 2003 edition of the Oklahoma Bankers Association Compliance Informer.
    
    First published on BankersOnline.com