This should be read in conjunction with the Presentation uploaded by me for Fraud Risk Assessments. This was presented along with presentation at the ACFE Middle East 2016 conference at Dubai by me
Falcon Invoice Discounting: Empowering Your Business Growth
Fraud Risk Assessment_Notes
1. FRAUD RISK ASSESSMENTS IN FINANCIAL INSTITUTIONS
Investigation reports and loss data provide the fertile ground on which the
seeds of a fraud risk assessment (FRA) can be sowed, and the ensuing
process should involve walk-throughs, sample testing, and, if allowed,
mystery shopping to identify the risk scenarios, efficiency of existing
controls, and residual risks.
CHARANJEET SINGH, CFE, CISM Head of Group Fraud Risk
Management A Leading Abu Dhabi–Based Bank
Charanjeet has experience of more than 18 years in the financial services
industry, of which the last 12 years have been in the field of control
functions, which include Fraud Risk Management and Internal Audit. He
has worked in three regions: India, Africa, and UAE. Charanjeet’s current
responsibilities include fraud risk management for one of the leading
banking groups in UAE, which also has international presence. His
responsibilities include creation and implementation of fraud risk policy,
along with management of the complete lifecycle of fraud risk, including
prevention, detection, and investigation, including regulatory reporting
related to fraud risk.
“Association of Certified Fraud Examiners,” “Certified Fraud Examiner,”
“CFE,” “ACFE,” and the ACFE Logo are trademarks owned by the Association
of Certified Fraud Examiners, Inc. The contents of this paper may not be
transmitted, re-published, modified, reproduced, distributed, copied, or sold
without the prior consent of the author.
FRAUD RISK ASSESSMENTS IN FINANCIAL INSTITUTIONS
What FRA Is and Why It Should Be Done
This is a frequently asked question and the answer lies in the fraud
triangle. The aim of FRA is to identify opportunities (fraud risks) that can
be exploited by fraudsters, both internal and external. Once the risks are
identified, they need to be mitigated or accepted, since it might not be
possible to eliminate them. FRA is usually part of fraud prevention tools
but sometimes it can become a detection tool. Fraud risk assessment
allows the organisation to identify the potential risks before they cause any
financial, reputational, or customer losses.
2. FRA can be done at two levels, the first being organisation wide to cover
areas related to organisational policies, and it is more of a checklist-based
activity. This helps in benchmarking the fraud risk management function
and can provide input in charting the roadmap.
The second type of FRA is done at the process or product level and is more
detailed. Even if an organisation is already conducting RCSA, internal
audits, and so on, it makes sense to conduct an FRA, because usually other
control tests evolve around pure operational risks and might not be as
detailed as the FRA in terms of approach. FRA involves meetings with
stakeholders, including people running the process on the floor, review of
SOPs and policies, data analytics, and testing of controls for design and
effectiveness. Depending on the organisational structure, process-level
FRA can be done jointly with RCSA or ops-risk teams.
FRA can also provide assurance to the stakeholders like board, regulators,
and insurance providers, but at the same time, if not conducted properly, it
can raise questions about the people who conducted it.
A process-level FRA should not be pitched as a control testing or control
evaluation exercise; rather, it should be presented as a joint exercise with
stakeholders to identify potential risk, map existing controls with those as
applicable, and identify residual risks and risk mitigating measures. The
tone of the FRA should be advisory and not mandatory for it to be
accepted.
In an organisation with minimal fraud incidents, a process- level FRA
might be a hard sell, but one look at operational losses and credit write offs
could provide an opening.
Ideally first step should be to conduct an organisation-level FRA as that
covers reorganization-level policies. The second stage should be the
process-level FRA.
How the FRA Should Be Done
For a stage-one FRA, which is organisational wide, a benchmarking
checklist provided by ACFE can be consulted. It covers prevention,
detection, and response. Some topics include:
1
3. ! Staff, vendor, and contractor background checks
! Presence of key policies like fraud risk, anti-bribery and
corruption, ethics and code of conduct declarations, whistleblowing,
mandatory leave, job rotation, and so on
! Response plan with responsibilities and accountability
! Presence of fraud awareness programs
A stage-two FRA is more comprehensive and for specific processes;
it involves control testing along with identification of mitigating
controls and acceptance of residual risks.
1
www.acfe.com/frat.aspx?id=6797 and www.acfe.com/uploadedfiles/acfe_website/
content/documents/fraud_pr ev_checkup_dl.pdf
It starts with identification of areas that are usually prone to fraud risk.
Common understanding is that there are certain high-risk functions, such
as procurement, sales, and other customer-facing functions. As FRA is a
resource-intensive process, one might want to focus on areas that are most
vulnerable and can cause high financial losses. Some factors to consider
while shortlisting the processes for FRA are:
! Past incidents in the company or in the industry
! Losses due to customers, staff, or vendors—sometimes
fraud is camouflaged under bad debts, operational
errors, etc.
! Cover all the processes under one department or cover
one process start to finish across the organisation
! Recent visits by other control functions like audit, OPS
risk, etc. Too many visits by control functions to a specific
department might result in a non-conducive environment for FRA. In
4. fact is it’s better to plan FRA before audit as buy in from
stakeholders could be higher.
! Resource availability with relevant skill set
Once the specific process or product has been identified, the idea of
an FRA should be discussed with stakeholders to check the
acceptance level. It might not be a great idea to push an FRA very
hard if there’s no buy-in from stakeholders. One should try to time
the FRA proposal with discussions of what has happened or what can
happen.
Though it is generally known that control functions are not the
masters of all trades, they are masters of control and risk domain.
Therefore, the FRA should be pitched for the areas where the fraud
risk team has good expertise. Additionally, the team should do the
groundwork before pitching FRA for any process so that certain
high-level risks can be shared with the stakeholders. This would get
the FRA team due respect, which can be leveraged during the FRA.
Expectations and deliverables should be discussed with the stakeholders to
ensure they are aligned and the usual disclaimers should be provided to
reassure the stakeholders that it’s a joint exercise unlike any audit and
would help the stakeholders in strengthening the process. This could be
done in the introductory meeting with the stakeholders. Usually it should
involve the head of the department, who should be asked to nominate key
people from the department for participation in the FRA.
Once the final decision and approval has been obtained for the FRA, team
should request all the relevant data, including the SOP, product notes,
policy, RCSA register, and so on. It’s always useful to read all the relevant
documents and identify the risks and mitigating controls. During this stage,
there could be scenarios wherein:
! Risk is identified in the process and a mitigating control is in place.
! Risk is identified in the process but a mitigating control does not exist
or is insufficient.
! A new risk is identified during the planning stage.
To ensure comprehensive recording of all the risks and mitigating
controls, it is advisable to document all of the above type of risks in
5. the FRA register.
During this stage, it’s not uncommon to ask the concerned team for
clarifications based on review of documents.
Once the FRA register is ready, the team should initiate the
fieldwork; some of the activities that can be undertaken during
fieldwork are:
! Meet with nominated people for brainstorming; they should be
encouraged to think of scenarios. Basic themes could be external
fraud (customer, vendor, third parties), internal fraud, collusion, etc.
! One should be able to create scenarios in terms of “what if....” Once a
risk scenario is visualized, then mitigating measures can be discussed
and agreed.
! It might be a good idea to take input from other stakeholders, for
example for an FRA of procurement function, consider input from
users of the products or services, whether they come across
specification changes, product quality, etc.
! Conduct a process walk-through to go through the process from start
to end, which also validates whether SOP and practice are aligned.
! Sample test to check whether controls are working as intended.
During the stakeholder meeting, they should be reassured regarding
objective of the FRA. It’s always fruitful to not have managers
present during such meetings; participants should include the people
who are processors. Later on, managers can be invited and asked for
their input. This is important as sometimes process executives might
not know about certain controls but managers might be aware of
them.
It is natural for managers to deny the existence of a risk and overrate
the effectiveness of a control; in such cases data gathered during the
planning stage can be very effective. The first step should be to get
the acknowledgement of the risk. It should be made clear that even if
a risk is completely mitigated, it needs to be documented in the FRA
6. register.
At least two rounds of meetings should be done with process executives
and process owners so that they have time to think about the risks and
mitigating measures. Effectiveness of controls can be tested during sample
testing. It might come as a surprise to the business team that controls that
exist in SOP are nonexistent in sample testing. It’s advisable to pick up
samples during the process walkthrough rather than asking for samples in
advance.
For example, in an FRA of the procurement function, the following type of
samples can be tested:
! RFP (request for proposal) process
! Vendor-selection process
! Vendor-empanelment process
! Vendor payment (how is it validated, quality/scope
coverage, TAT for payments, how the payments are made, if it’s
electronic fund transfer how are the bank details obtained from the
vendor, process for changing bank details of vendor, how are the
duplicates identified)
In an FRA of HR (hiring process), some risks could be:
! Routing of direct candidates through an agency
! Agency hiring process
! Payment of joining bonus—candidate not paid anything
or paid a lower amount but records indicate a higher
payment
! Payment of unclaimed allowances to account of an
accomplice
7. ! Not conducting background checks or conducting
inadequate background checks
! Candidate providing fictitious degrees or certificates
! Staff collusion resulting in defective maker-checker
control
! Fake resume, work experience, specific projects, length
of service, designation, compensation, etc.
! Stage-managed background checks
! ID theft, remote testing
! Terminated ex-staff is able to join back in a different
division, department, or subsidiary
In the FRA of a process that has an OTP (one-time password) or
callback, some of the important risk factors could be identified by
asking:
! How was the phone number on which OTP is sent
added?
! What is the process for updating a phone number?
! How is the risk of the phone number being
compromised mitigated?
! How is the risk of MITM/MITB mitigated through an
OTP or callback?
! Are the callback questions limited to only the
transaction confirmation or do they also include
customer identification?
8. ! Are the customer identification questions based on
static data or do they include dynamic questions?
All the risks identified based on SOP review, brainstorming exercises,
process walkthroughs, and control testing should be documented and
shared with the concerned business team for review and input on the
mitigating controls. This could result in:
! Risks that are sufficiently mitigated ! Risks that are partiality mitigated
! Risks that can’t be mitigated
All of these should be evaluated in terms of probability of occurrence,
impact, control design, control implementation effectiveness, residual risk,
and risk rating of the same.
Some of the risks identified through FRA might require action planning as
at times mitigating controls can’t be implemented immediately due to
various reasons. These could include changes to process, policies, and
certain non- mitigated risks that might require management
acknowledgement through signoffs.
Sometimes certain operational risks get identified during FRA activity and
they should be classified as such in case they are not documented already
under RCSA. Similarly if a risk is identified but it can’t be owned by the
process under FRA, it should be referred to the concerned team to address
it.
Presenting the Findings
After finalisation of risks and completion of FRA register, high-level risks
can be shared with stakeholders in the executive summary along with
detailed report covering all the identified risks. One can consider rating the
process but the ratings should be well defined to bring out the objectivity,
otherwise it can result in challenges. Ideally the overall report format
should be discussed with stakeholders in the planning stage.
For effective action tracking of FRA findings, it is advisable to conduct a
closure meeting with the department head, and findings can be jointly
presented by a team comprising fraud risk and business.
9. Action Follow-Up
Action follow-up can be done on due dates if the fraud risk team has the
resources, or in the report this responsibility can be assigned to the
business team and an annual declaration can be obtained confirming the
implementation of action plan as per the agreed dates. These reports could
be shared with internal audit department as they could test controls during
the audit of concerned business team in due course.
Any fraud incidents that happen subsequent to the FRA should be checked
to see if they form part of identified risks or if it is a new risk that could
not be identified during the FRA. Similarly if a fraud scenario was already
identified during the FRA, someone should check whether the control
design was defective or if the control did not work as intended. Such
incidents should be considered when scheduling the next FRA for the
specific process area.
Supporting Steps:
Fraud risks can be identified in planning stage through:
! Review of SOP, policies, and product papers
! RCSA or operational risk assessment reports
! Loss data
! Customer complaints
! Regulatory reporting
! Insurance claims
! Industry sources
A sample FRA register might have the following sections:
! Fraud risk type: internal, external, combination
! Fraud risk scenario
! Risk identification stage: planning, fieldwork, existing
risk (RCSA/ORA etc.)
10. ! Probability of occurrence
! Risk impact
! Mitigating control
! Residual risk
! Residual risk impact
! Action planning
! Action owner (there could be some risks for which
ownership is outside the specific process so concerned
people should be informed about it)
! Action completion date
Probability could be classified as high likely, likely, or not likely. Control
design could be classified as effective or defective. Control effectiveness
can be classified as no exceptions noted, exceptions noted, or not being
followed. Residual risk could be high, medium, or low.
Some of the high-risk functions across industries include: ! Sales function
! HR
! Procurement
! Payments
! Admin: leasing, services management ! Operations
Broadly, customer-facing and vendor-facing functions are prone to
corruption and bribery. Processing teams could either aid the fraud due to
negligence or be tempted by internal or external entities.