In my consulting career, I often supported banks in the review or creation of fraud program documentation. Oftentimes, I found that enterprise fraud policy documentation lacked sufficient detail, with common gaps related to fraud definitions and examples, roles and responsibilities across the organization, and program governance. These common gaps can lead to program pitfalls, spanning day-to-day misses all the way to regulatory trouble. For example, a lack of sufficient detail related to roles and responsibilities across the organization can lead to several problems, such as:
- Redundancy (the same task being completed by multiple teams in different ways, causing downstream confusion).
- Lack of a cohesive understanding of the program and who does what.
- Key fraud controls and activities lacking a clear owner, leading to those activities not being performed or being performed in an ad hoc manner.
- Confusion across the organization about whom to contact with fraud-related questions or how to raise potential fraud concerns to the right people on the fraud team.
Documentation isn’t a novel or hard-hitting topic. For this reason, among others, I’ve seen fraud program documentation fall to the wayside as shiny, new fraud tools and constant fraud attacks steal the focus. However, documenting your fraud risk management program is essential and requires a strong foundation that includes policies, standards and a program framework to be successful. Fraud program documentation gaps can cause problems that might not surface until later, and at that point the damage may be done.
Why documentation falls to the wayside
In my experience, organizations disregard fraud program documentation for two main reasons:
- Program documentation is no one’s job. Oftentimes, busy, overloaded fraud teams overlook documentation because it’s no single person’s job, or it’s an additional requirement above and beyond their day-to-day mandates. This lack of ownership and focus can lead to outdated documentation or a lack of documentation altogether.
- The focus is on everything but documentation. The focus of the fraud program is on the fraud technology stack or ecosystem, on capacity planning, or on handling the latest crisis. Fraud program documentation continues to get pushed down the list of priorities time and time again because the focus is on everything but building the program’s foundation.
Creating an enterprise-level fraud policy
Gaps in fraud program documentation may take time to cause a problem or become apparent, but they can lead to significant and costly problems down the line. To avoid headaches, take the time to develop an enterprise-level fraud policy and a program document.
Your fraud policy sets the tone for fraud risk management for the entire organization. It’s an external-facing document, meaning it isn’t a fraud-team-only resource but a resource for every employee, department and team. A solid enterprise-level fraud policy defines the organization’s approach to fraud risk management and the role each person plays within the organization. Key topics to cover in a fraud policy include:
- Fraud definitions, including fraud and internal versus external fraud (at a minimum), with organization-relevant examples to bring those definitions to life.
- Fraud program roles and responsibilities, including the role that functional or ecosystem partners play in the fraud program, such as cybersecurity, legal or compliance positions.
- Program governance, including the fraud-specific committee or working group and its connection to the broader governance structure at the organization, and how key fraud reports reach senior leadership or the board of directors.
- Fraud risk management framework, including how the organization structures, approaches and oversees the components of the program.
Your fraud risk management framework should be tailored to your organization and may align with applicable industry standard frameworks. For example, the Committee of Sponsoring Organizations of the Treadway Commission (COSO) and the Association of Certified Fraud Examiners’ (ACFE) Fraud Risk Management Guide outline five key principles that can be translated into program components. Your organization can then create a tailored definition and approach while defining roles for each component and documenting them in your policy. You can also leverage industry-specific resources. For example, in the banking space, the Office of the Comptroller of the Currency’s Fraud Risk Management Principles provides an initial framework that you can tailor to your organization. (See “Operational Risk: Fraud Risk Management Principles,” Office of the Comptroller of the Currency Bulletin 2019-37, July 24, 2019.)
Documenting your fraud risk management program is essential and requires a strong foundation that includes policies, standards and a program framework to be successful.
These principles and their underlying guidance also serve as a useful benchmark tool to identify gaps in your framework and to determine whether your framework is generally in line with standard practices. For example, does your policy adequately define your approach, roles and responsibilities for fraud examinations or for the enterprise fraud training and awareness program? Both topics, covered in the guidance above, would help you catch potential gaps or gather ideas for expanding your program.
In addition, you’ll want to consider the purpose and scope of the policy; procedures for addressing exceptions to the policy; the cadence for review and updating the policy (including an annual and off-cycle process with defined owners and approvers); related documents, such as a whistleblower protection policy; and related regulatory requirements (including how the program addresses each and where they reside in the framework).
The list could go on, but the bottom line is that what you include in your policy has some wiggle room. The point is to tailor what you include for your organization while ensuring that you incorporate the key elements with enough detail to provide clarity from the top down and across your organization. When in doubt, remember that you’re aiming to build a solid program foundation without gaps that may cause harm down the line.
Crafting a fraud program document
While an enterprise fraud policy is an external-facing document, a program document is internal-facing, meaning a program document is built by and for the fraud program. It documents the inner workings of the program at a lower level than the policy in terms of detail and granularity. For this reason, some of the components — including roles and responsibilities and the fraud risk management framework — will parallel the policy, with the intent of diving deeper into the program document.
As highlighted in the key topics to cover in a fraud policy, be sure to drill down into the roles and responsibilities when creating your program document. For example, the broader fraud examinations team may have multiple underlying teams. Outlining each underlying team and its unique role may not be needed in the policy but should be detailed in the program document. Additionally, the overarching fraud program organizational chart and individual team-level organizational charts should be included in the program document. Organizational charts should focus on roles instead of naming specific individuals to avoid having to make frequent updates as team members shift around.
You should mirror the fraud risk management framework outlined in your fraud policy in greater detail in your program document. For example, if one component of your framework centers on fraud training and awareness, you can provide in-depth details in the program document, including an annual calendar that outlines audience, modality or channel, and topic.
In addition to the above items, the program document should cover all the other inner workings of the program. Here’s a list of possible topics to include:
- Fraud program strategy and roadmap: An outline of strategic priorities, ongoing initiatives, and future enhancements with a clear roadmap, and a defined approach to measure the success of the strategy and its underlying initiatives.
- Fraud technology stack or ecosystem: An outline of the technology tools used across the fraud program, including the related vendor, the team or teams using each tool, and the purpose of the tool.
- Third-party/vendor projects: A listing of all planned or ongoing projects with third parties, such as contractors or consultants and vendors, including who the third party is, the project owner, the purpose of the project, the status, and key timeline or milestone dates.
Like your fraud policy, you should tailor what you include in your program document to your organization. The topics in this column illustrate some of the key areas to consider. This type of documentation hasn’t always been top of mind for people, and the details generally exist in multiple places throughout an organization. The benefits of bringing all this together in one place include regulatory compliance or a reduction in potential compliance risk; clarity on the fraud program’s inner workings and components; use of the program document in onboarding new team members; and use of the program document in answering audit, oversight or regulatory questions.
Fraud program documentation is not a thing of the past. Across industries and regardless of company size, a strong foundation ensures effective and efficient fraud risk management. At a minimum, fraud policy and program documentation provide a solid platform for you to build and expand on.
Sophia Carlton, CFE, is a fraud risk executive at SoFi. Contact her at sophiacarltoncfe@gmail.com.