Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK
A financial crime classification tool for developing financial crime solutions
This white paper presents a conceptual framework to assist in the

identification of crime risk, as well as associated business and system
capabilities to control crime. While it can be used for various forms of
crime risk, this paper focuses on financial crime in retail banking
institutions.
__________________________
Copyright © 2011, Michael Gallias
Revision: 17 April, 2011
Up to one full page of this white paper may be

quoted without express written permission of the
author.
__________________________
A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 2
Contents
Using the Matrix for Identifying Financial Crime Scenarios ___________________ 3

Understanding the Who-What Matrix ________________________________________ 3
Introduction ___________________________________________________________________ 3
The High-Level Retail Financial Crime Who-What Matrix _______________________________ 3
The Generic Crime Who-What Matrix ______________________________________________ 4
Example: Using the Matrix for Nomenclature ________________________________________ 8
Adapting the Who-What Matrix for Solving Specific Crimes ______________________ 9
Identifying Risks and Brainstorming for Solutions by Product ____________________________ 9
Identifying Risks and Brainstorming for Solutions for a Single Product by Channel __________ 11
Identifying Risks and Brainstorming for Solutions by Channel __________________________ 12
Conclusion _____________________________________________________________ 13
Using the Matrix for Solving Financial Crime Scenarios _____________________ 14
Introduction ___________________________________________________________ 14
Determining Needed Capabilities __________________________________________ 14
Excursus: An Argument for Developing Business Capability By Studying System
Capability ____________________________________________________________________ 15
Using the Who-What Matrix to Select Capabilities ___________________________________ 15
Using the Scenario-How Matrix to Select Capabilities _________________________________ 17
Testing Vendor and Technology Decisions with Traditional Tools _______________________ 21
Example: Using the Matrix to Determine Data Requirements for a Set of Scenarios_________ 23
Conclusion _____________________________________________________________ 24
Summary __________________________________________________________ 25
Using the Matrix for Identifying Financial Crime Scenarios
Understanding the Who-What Matrix
Introduction
By mapping who might be perpetrating a financial crime against what exact financial crime they
may be committing, a matrix is created that assists leaders in the financial crime control world
to plan their business structures, their strategies and their required capabilities. In addition, it
helps create a common conceptual framework and language within an organisation for effective
communication within a crime control department.
This technique may be extended to other industries (briefly mentioned later), but the focus of
this paper will be the retail banking financial crime solutions arena.
The High-Level Retail Financial Crime Who-What Matrix
What Violations of
Money Terrorism Product Product
Regulatory
Laundering Finance Application Fraud Use Fraud
Who Compliance
Rogue Organisation
Internal
Rogue Employee
First Party
External
Third Party
On the far left one has the two primary categories where one may find criminals: criminals
inside the organisation and criminals outside the organisation. In other words, “Who” refers to
who is committing the crime (not who is being targeted, although creating such a matrix may
also have some benefit). Internal fraud may be further categorised as rogue organisation and
rogue employee. The former, rogue organisation, is an organisation that, at executive level,
makes strategic decisions that are criminal. The employees who carry out the instructions of
the executives may or may not be aware that they are involved in criminal activity. The
organisation may have a genuine business service it provides, and engages in criminal activity as
a side line, or it may be a front, such as a false “charity” that does no charity work at all, it
merely launders drug money. The latter category, rogue employee, is an employee within a
legitimate business who is involved in criminal activity. This may be, for example, because they
are part of a syndicate, or because they have been pressured by criminals into assisting them.
The rogue employee may engage in simple theft independently, or may collude with others to
concoct complex methods to deceive managers and fellow employees in order to gain funds or
products from the organisation, its employees or its customers.
Within the category of criminals outside the organisation, one can broadly categorise the
perpetrators as first party criminals or third party criminals. For example, customers who
commit fraud against their bank using their own credit card would be first party fraudsters,
while those skimming a bank’s customer’s credit card would be third party fraudsters.
Across the top of the matrix are the primary types of financial crime an organisation would be
concerned with. In other words, “What” refers to what crime is bring committed. First, there is
the local regulatory compliance specific to the region. For example, in South Africa it is illegal to
withdraw more than a certain amount of money per day unless a proof of residence has been
supplied to the bank. Second, one has the classic anti-money-laundering problem facing banks,
where circular flows of money need to be detected to prevent persons from hiding their sources
of income. Third, counter terrorism finance is the detection of linear flows of money, for
example, numerous people filter money through numerous false charity organisations and
those funds eventually reach a terrorist organisation’s account. More and more countries are
requiring banks to monitor for this type of behaviour.
The remaining two categories are the classic, primary fraud categories, application fraud and
transaction fraud. Application fraud refers to persons applying for a bank’s financial offerings
(retail product) with intent to deceive and steal. Transaction fraud refers to the misuse of an
already issued financial offering with intent to deceive and steal.
For simplicity, in most of this paper I assume the employee or organisation is rogue (i.e., has
intent to commit a crime).
The Generic Crime Who-What Matrix
Product application fraud would better be called relationship initiation screening and product
use fraud could be party activity monitoring (where party is defined as “person or group of
people constituting a particular side in a contract”). This makes the cases of internal fraud more
coherent (when an employee wants to join the organisation, that employee is starting a
relationship, not necessarily applying for a product—and when a customer applies for a financial
product, they are in effect starting a relationship), but for the purposes of this paper, I will use
the traditional terms as they are more common within the financial industry. Thus, within this
paper, product use fraud includes the employee misusing office equipment. In effect, any
resource within the organisation becomes a “product” from the employee perspective in this
framework.
One should also introduce a less familiar concept, that of party status monitoring. This is
different to party activity monitoring because it monitors the status of the party, not by
screening the party’s activity with the organisation, but rather by monitoring the party’s status
in the industry or country. For example, banking industries may share a black list of known
fraudsters. If customer F holds products at banks X and Y, and F defrauds bank X, when X
publishes F on the industry list, Y should close F’s account even though no activity of F in bank Y
raised any suspicion of fraud. This may include sanctions screening. For example, if a customer
of a bank is listed on a terrorist list by the United Nations, the bank may be required to
terminate the relationship with the customer even though no specific activity thus far may be
suspicious.
When the financial crime matrix used outside of financial industry, the matrix can be more
generically depicted as follows.
Relationship Initiation Party Status Party Activity

What Screening Monitoring Monitoring
Who Compliance Fraud Compliance Fraud Compliance Fraud
Organisation
Internal
Employee
First Party
External
Third Party
The following is an equivalent.
Compliance Fraud
What
Relationship Party Party Relationship Party Party
Who Initiation Status Activity Initiation Status Activity
Screening Monitoring Monitoring Screening Monitoring Monitoring
Organisation
Internal
Employee
First Party
External
Third Party
The first three columns can sometimes be combined for the sake of simplicity.
What Regulatory Relationship Party Party

Compliance Initiation Status Activity
Who Management Screening Monitoring Monitoring
Organisation
Internal
Employee
First Party
External
Third Party
Furthermore, the first column is actually unnecessary if the latter three columns cover all
crimes, not just fraud. However, they are usually separated because certain crimes benefit
organisations, and governments force organisations to address specific crimes. For example,
money laundering can be “very good” for a retail bank because they earn bank charges on each
transfer (the fact that the source of the money is, say, illegal drug trade, will not bother some
banks). Thus the latter three columns typically cover only those crimes that are in the
organisation’s best interest to monitor (what is best for them or their customers).
This simplified generic matrix can be used within the financial services industry if the first
column is seen to include money laundering and terror financing. Here are some examples for
the purposes of clarity.
Relationship Party Party

What
Regulatory Compliance Initiation Status Activity
Management Screening for Monitoring for Monitoring for
Who
Fraud Fraud Fraud
01 02 03 04
Orga ni s a tion mi s s es the

Orga ni s a tion a ppea rs on a
Organisation dea dl i ne for green energy N/A
wa tch l i s t
N/A
l a ws
Internal
05 06 07 08
Empl oyee i l l ega l l y Empl oyee col l udes to gra nt

Pros pective empl oyee i s Empl oyee a ppea rs on
Employee vi ews a nd s ha res
on pol i ce l i s t i ndus try wa tch l i s t
a ppl i ca tion of product to
a ccount detai l s fra uds ter
09 10 11 12
Cus tomer a ppea rs on

Cus tomer vi ol a tes l oca l Pros pective cus tomer i s on Cus tomer l ogs fa l s e cl a i m
First Party wi thdra wa l l a w i ndus try bl a ck l i s t
pol i tica l l y expos ed
on credi t ca rd
pers ons l i s t
External
13 14 15 16
Terrori s t tri cks cus tomer Cus tomer ha s been

Fra uds ter s ki ms debi t ca rd
Third Party a nd then recei ves tra ns fer N/A tra ns ferri ng l a rge s ums to
a nd dra ws money a t ATM
from cus tomer newl y di s covered fra uds ter
Working from left to right and top to bottom, here are some examples of crime scenarios (there
are many that could be placed in each block). (I define a rogue organisation as an organisation
that purposefully commits a crime. Not every organisation commits crimes intentionally.)
Crimes perpetrated by the organisation itself:
1. While an rogue organisation could monitor that it doesn’t purposefully contravene local
regulations, this is, for all intents and purposes, a meaningless scenario since a corrupt
organisation is hardly going to monitor and report itself. In the case of an honest
organisation, a project may run behind schedule and it may contravene a new energy
law.
2. An organisation cannot, under ordinary circumstances, start a relationship with itself.
3. This is, like scenario 2, fairly meaningless. However, a rogue organisation might monitor
its own status to know whether it had been caught (perhaps it operated in multiple
countries, such down an operation and left a country, then was placed on a police list in
a country other than its current operating country). In this case, a rouge organisation is
doing financial crime detection to protect itself! One may think that a more likely
scenario is that a genuine organisation would monitor lists of known legitimate and
corrupt organisations in order to protect its reputation (either it is mistakenly
blacklisted, a company with a similar name gets blacklisted, or someone illegally takes
control of the organisation in the country’s central list of directors and owners, as
happened in South Africa during 2010). However, in this latter case, the scenario does
not fit in this block but in the third party block, 15. This is because the rows indicate who
is perpetrating the crime, not the victim of the crime.
4. An organisation cannot defraud itself, making this scenario meaningless.
Crimes perpetrated by an employee in the organisation:
5. Here a rogue employee violates local law, even if it does not harm the organisation itself.
This may also be an honest employee improperly trained.
6. When a prospect applies for a job, they are found to be on a published police list, making
them unsuitable for the sensitive position offered.
7. An existing employee, who passed initial screening, now appears on a watch list of
known criminals.
8. In this scenario, an employee performs activity on the IT systems to assist a fraudster
obtain an account, and this might be detected by some sort of internal fraud
activity/pattern detection system.
Crimes perpetrated by a customer of the organisation:
9. The customer violates local limits on a cash withdrawal. (This assumes there is no inline
IT system to prevent this from occurring. If there is such a system, the customer would
probably be prevented from committing the crime, and then informed that the reason
for the declined transaction is that local law prohibits it.) Alternatively, the customer
appeared on a politically exposed persons (PEP) list, and must now receive enhanced
due diligence (EDD) checks on a regular basis.
10. When a party applies for a product or account, that party is found to be on an industry
watch list, and the application is declined.
11. Although the customer was not on any watch lists when originally applying for a product,
the customer has since appeared on a black list.
12. The customer tries to defraud the organisation by making purchases and claiming for a
fraud refund even though the transactions are not fraudulent.
Crimes perpetrated by a third party:
13. An existing customer transfers money, directly or indirectly, to a known terrorist. This is
actually a first party crime if the customer knows the third party is a terrorist, but may be
a third party crime if the terrorist tricked the customer into transferring the money
(which is also fraud). Certain money mules may also fall into this category.
14. This is a meaningless scenario since it is not ordinarily possible to initiate a relationship
with a third party since the third party would then become a first party, by definition.
15. By monitoring third parties, which is ordinarily impossible in the average retail bank
since the banks often do not know the full identities of all their customer’s first parties
(and even if they did, the task may be beyond the capabilities of most of today’s
systems), it may be possible to identify a newly discovered fraudster, indicating that an
honest-looking customer is doing business with a fraudster. This may mean the honest-
looking customer is also a fraudster, or is possibly being defrauded. This scenario (block)
is more likely to apply in the case of investigators using link analysis tools given the state
of current IT systems.
16. This is the most classic fraud scenario: a third party defrauds an existing customer, and
this is detected by using fraud detection systems to monitor customer behaviour and
patterns.
Example: Using the Matrix for Nomenclature
Using this classification matrix, an organisation can derive a common language or financial crime
nomenclature. (Within the crime solutions industry, there is significant disagreement over
terminology.) At a most basic level, all five columns would be considered financial crime, but
only the last two columns would be considered fraud. One can then focus on specific areas, for
example, application fraud.
What Violations of
Regulatory
Who Compliance
Rogue Organisation
Internal
Rogue Employee
Ap
pl
ic
at
io
n
Fr
au
First Party
d
External
Third Party
The first block in application fraud would not be a concern to the typical bank, as it is relatively
meaningless (an organisation does not usually start a relationship with itself). It is important to
mark this so that everyone suing the matrix can visibly see the problem space and focus their
attention on the area of concern. Here the matrix is used to focus attention on all possible
means of application fraud.
What Violations of
Regulatory
Who Compliance
Rogue Organisation
Internal
Rogue Employee
Ap
pl
ic
at
First Party
io
External
n
Fr
au
d
Third Party
The first party fraud scenario would appear as follows in the matrix. (I shall call each block or
group of blocks a “crime scenario”.)
What Violations of
Regulatory
Who Compliance
Rogue Organisation
Internal
Rogue Employee
Fra ud
First Party Party
Fir st
External
Third Party
Ideally, an organisation would want a single department responsible for the entire matrix
because there is typically overlap in skills and capabilities required for each block in the matrix.
This is not always possible, and there may be specialist departments or IT systems for specific
crime scenarios.
Adapting the Who-What Matrix for Solving Specific Crimes

The matrix can be used in a number of ways, depending on the enterprise’s needs and the
organisation’s specific approach to solving crime.
Identifying Risks and Brainstorming for Solutions by Product
If one “zooms in” on one particular high level crime scenario (one of the blocks in the who-what
matrix), one can analyse the risks associated with that scenario in more detail by breaking it into
separate, lower-level scenarios. By way of example, the below matrix shows how to identify
risks within third party product use fraud, often called third party transaction fraud. (In other
words, the new matrix is a “zoom in” of the very bottom far right block of the main matrix first
presented.)
What Violations of
Regulatory
Who Compliance
Rogue Organisation
Internal
Rogue Employee
First Party
External
Third Party
Product Use Fraud

Credit Card Debit Card Gift Card Current Account Loan Account
External Third Parties
Stranger
Friend
External
Family
Member
Business Partner
Automated Software
Here, the product use fraud column (the far right column in the main matrix) is divided into
further columns, creating “sub-columns”. The third party row of the main matrix (the lowest
row in the matrix) is divided into sub-rows.
In this particular case, the hypothetical organisation has chosen to create a column for each of
their products. The new rows are the persons who may be involved in fraud (these are perhaps
identified using brainstorming). Thus rows are who may commit fraud, and columns are what
mechanism they are using to commit fraud. Each block becomes a transaction fraud scenario.
Product Use Fraud

Credit Card Debit Card Gift Card Current Account Loan Account
External Third Parties
Stranger
Friend
External
Family
Member
Business Partner
Automated Software
During a brainstorming session to understand each scenario, additional rows may be added as
various ideas and experiences help create as many rows as needed, increasing the number of
crime scenarios (within reason, they need to be grouped wherever possible). This is important
because the more scenarios that are created, the easier it is to understand the potential crime.
The better each crime is understood, the greater the opportunities for finding solutions to each
identified risk.
This can become complex in that it is quite possible a friend and a family member of a credit
card holder could form a syndicate and use automated software to rob the card holder. But at
least the individual scenarios are listed, even if all combinations are more difficult to diagram.
(It is possible, however, to colour certain blocks together to identify a specific combination fraud
scenario, showing possible collusion.)
When brainstorming, it can be helpful to compile a list of questions to ask. For example, the
following questions may be of value as each crime scenario is explored.
 Who is able to commit the crime?

 Who may be targeted (who are the potential victims)?
 Which laws are being broken and how will the criminal commit the crime?
 What triggers the need for a financial crime check? For example, changes to the blacklist
were made during the day. (It is important to differential between the triggering event
and the data check required. A transaction may be an event that triggers a check against
a customer watch list. The transaction event may not contain all the customer data.)
 What is needed to detect the crime (what data, capabilities and services are needed to
detect the crime scenario)?
 What system event can be used to trigger the financial crime check? For example, the
time of day may start an offline, nightly process to check all customers that had a change
of details during that day against the sanctions lists; for real-time internal fraud
scenarios, a system login event may be the trigger for a financial crime check.
 What is needed to mitigate the risk of the crime (what events, data, capabilities and
services are needed to prevent or reverse the crime scenario)?
 Should the problem be addressed as a security issue (typically authentication and
authorisation processes) or a financial crime issue?
 What information is needed to prosecute (what does the legal department need if a
crime is committed and the perpetrator is identified and caught)?
 Can existing systems be leveraged for the required capabilities? For example, if credit-
risk decision agents exist for origination or account maintenance, can they be updated to
do financial crime checks?
Identifying Risks and Brainstorming for Solutions for a Single Product by Channel
One can “zoom up” again (create another matrix within the matrix that is within the original
who-what matrix). For example, if one takes the upper left block in the above matrix (the
scenario of a stranger defrauding a credit card holder) and create another who-what matrix, one
may get the following.
Credit Card Use Fraud (Channel) Online Mobile

(Internet (Internet Phone IVR Branch ATM
Strangers Shopping) Shopping)
Individual
Colluder with
Staff
External
Colluder with
First Party
Mob
Syndicate
Across the matrix one has new sub-sub-columns, each indicating the various channels where the
credit card might be used. (Interactive Voice Response, IVR, may be included because the
fraudster may phone the bank and change the card’s PIN. It is thus a channel that creates crime
scenarios that must be considered.) In the sub-sub-rows, one has various ideas as to who the
stranger or group of strangers might be.
In each case of fraud (deception with intent for illegitimate gain) one should consider who the
target of the fraud may be. The matrix could, in theory, be used to create columns for
fraudster’s target (the organisation itself, its employees or its customers—or perhaps even non-
customers that somehow are defrauded via a fraudster misusing an organisation’s facilities). In
other words, when brainstorming how a particular crime scenario could be perpetrated, one
may realise that the customer is being targeted, but the organisation may face reputational risk,
or may be legally responsible for the customer’s loss. The goal of brainstorming with the who-
what matrix is to gain as much information as possible about the crime scenarios of concern.
Identifying Risks and Brainstorming for Solutions by Channel
One needn’t start by zooming in using products, one could use any concern the bank may have,
for example, channel.
Channel Fraud Online Mobile

External First Parties Shopping) Shopping)
Primary Card Holder

External
Secondary Card Holder
Unofficial Card Sharer

In this case one is looking at first parties (from the main matrix) who may be involved in fraud
and one has the various channels across the matrix.
When numerous types of fraud are perpetrated across multiple channels, yet there is a single
party, one may represent the problem as follows.
Channel Fraud Online Mobile

External First Parties Shopping) Shopping)
ra ud
Primary Card Holder Party Channel F
Fir st lti -
Mu
External
Secondary Card Holder
Unofficial Card Sharer
In this case, a particular category of first-party multi-channel fraud has been identified as a
concern for discussion (“first-party multi-channel fraud” applies to the other two rows as well,
since if the secondary card holder is a customer of the bank, or the customer has a shared card,
they are still first parties committing fraud across multiple channels). This would be relatively
unusual, since multi-channel fraud usually refers to third parties, but the matrix shows how a
who-what matrix assists one in highlighting every possible risk, real and imagined, both of low
or high probability. Again, some scenarios are difficult to indicate, and perhaps multiple
matrices and colours may be needed. For example, it is quite possible that the primary and
secondary card holders are blackmailed by a third party that is involved in a syndicate using
automated software to commit fraud by using inside information provided by a coerced
employee (who in turn was coerced by an employee who was a part of the syndicate)! The
possibilities are endless.
It is worth noting that the matrix is a tool for understanding the problem domain and exploring
solutions, it is not a presentation tool. The output of the process is better presented in the form
of a report containing lists or other visualisation techniques.
Conclusion
In short, the who-what matrix can assist an enterprise in understanding risk. It provides a
common language and conceptual framework within an organisation, and it is a tool for
brainstorming possible crime scenarios. “Who” represents the parties that are committing the
crime. “What” represents what the criminals are doing (or, if needed, how they are committing
the crime).
Using the Matrix for Solving Financial Crime Scenarios
Introduction
Using the methods in the previous section, an organisation could identify all the financial crime
scenarios that concerned it. In this section I discuss how an enterprise can solve the particular
scenarios under consideration using capabilities specific to their concerns. This document
assumes the three primary categories are
 business capability
 system capability
 vendor capability
but will focus primarily on the system capabilities.
Determining Needed Capabilities

Capabilities are typically divided into business capabilities and system capabilities. The former
refers to the various functions the business needs to be able to perform to solve the scenarios.
(This may include the necessary business architecture and organisation design, along with filling
those roles and instilling the necessary skills and, importantly, culture, to address the scenario.)
An organisation will also need systems to address the IT capabilities needed. This is typically
done by means of a request for information (RFI) to numerous vendors, preferably including
product demonstrations by the vendor. In this phase, it is typically best to survey as many
vendors as possible to understand the capability landscape, which helps one develop a potential
system capability map. From this complete potential system capability map, the organisation
can match their business needs to the system needs. This capability map will depend on the
country and the time of the RFI. This is because not all financial crime solution vendors operate
in all countries, and vendors introduce new capabilities over time.
Business Capabilities System Capabilities System Vendor Capabilities Other Vendor Capabilities
It is important to understand all the possible capabilities and group them appropriately, so one
can “pick and choose” the required capabilities for the scenarios being addressed. It may
become evident, however, while doing the following exercises, that a particular capability was
missed during this mapping process. A vendor may then need to be sourced for that specific
capability.
Excursus: An Argument for Developing Business Capability By Studying System Capability
Within most organisations, the business requirements are used to select a system. In other
words, the business is assumed to be mature enough to know what type of technology it needs,
and that technology is tailored to fit the enterprise’s requirements. I am convinced this is
becoming less true over time because of the pace of technological development in some areas.
Especially in the financial crime landscape, criminals are necessarily more mature in their crime
thinking than the business. Typically, the business is reacting to various financial crimes as they
appear, rather than being proactive. This may be because executive leaders often spend on
areas that produce profit rather than areas that reduce risk of loss. This aggravates the
situation, giving criminals the upper hand, with most organisations on the back foot in their fight
against crime.
Developing an agile and proactive approach to financial crime is thus exceptionally difficult.
One usually has budget to deal with realised risk but not potential risk. The business can thus
become full of “miniature departments” specialising in the financial crimes that are draining the
business of its profits at that moment in time. By the time one crisis has been managed, the
specialists are learning about the next hole that fraudsters have managed to discover in the
enterprise.
I thus argue than in the case of financial crime, one should not develop a business architecture
and follow it with a system architecture to meet the various requirements and use cases, but
rather develop the business architecture and capability once one understands industry best
practice within the system capability arena. This is because the best fraud vendors have
worldwide experience in all financial crime, not just the scenarios the organisation is currently
facing. By building a business architecture around the full spectrum of system capabilities (the
world’s best and most agile technical solutions), the organisation becomes agile in solving all
financial crimes as and when they arrive, significantly mitigating the surprise factor of future
financial crime—and thus the associated high costs thereof. This also makes sense simply
because, especially in the area of retail banking, fraud is typically committed with technology,
and it is technology that is the primary force in mitigating crime risk. Clever business processes
without technology will mitigate almost no risk because of the high speed and volume of
applications and transactions in the modern environment. Yet gold-standard technology (out-
the-box deployments of a vendor’s product with their best-practice configuration) without
clever business processes will mitigate a significant amount of risk. The ideal is to have both,
but the starting point in today’s environment is usually technology.
Using the Who-What Matrix to Select Capabilities
The matrix can be used to allocate either vendor, business or system capabilities to a particular
scenario or set of scenarios.
Credit Card Use Fraud (Channel) Online Mobile

Strangers Shopping) Shopping)
Individual
Colluder with
Staff
External
Colluder with
First Party
Mob
sis omise lysis rio

Scena olving n
Syndicate Anal y ss Compr A na time ula tio
* Li nk * M a *R ea l- S * Sim
In the above hypothetical example, an enterprise has identified that it needs to address the area
of cross-channel financial crime in the credit card space, where syndicates are defrauding the
organisation. They have identified the following system capabilities. (This is just a random
sample of the many capabilities that are available, for the purposes of demonstrating how the
who-what matrix can be used.)
 Link analysis, also called graphical relationship analysis or entity link analysis, is a
capability that displays relationships between data graphically because those
relationships are not obvious when viewing thousands of lines of data. For example, a
group of businesses sharing a postal address would indicate possible suspicious activity.
 Mass compromise analysis (in real-time, near-real-time, batch or offline) detects
patterns in data highlighting an area that the syndicate will be targeting in the
enterprise. For example, the syndicate may be targeting point of sale (POS) devices in
the city centre.
 Real-time scenario solving is the ability to create new analytical models and rules to
produce scores, and have them execute against incoming data to produce a financial
crime risk score (probability), and prevent crime from occurring if the score is high. The
probability would probably be a number from 0.01% to 99.9%. (Obviously no system can
determine with absolute certainty that a particular event is either 0% or 100% criminal.)
 Simulation allows the users to test their scenario solving criteria before impacting their
live system. For example, changing a rule may increase the false-positive ratio
significantly, and while it may improve financial crime detection, it might be impractical
given staffing quotas.
Security capabilities to deal with financial crime must also be considered (for example,
mechanisms for authentication and authorisation), but are not considered here. I separate
crime risk management and security. Crime risk management applies once security has been
breached without the knowledge of the organisation. For example, authentication by password
is security. If a fraudster steals a password, the security system cannot detect this. Typically, a
crime risk management system must detect this.
In each case the organisation would need to select a vendor for each IT system capability, or,
better, a single vendor for all of those capabilities, making management of the system simpler.
(This is typically a trade-off of cost and manageability versus best-of-breed. One solution may
do everything fairly well, but getting specialist technology for each capability allows one to
cover a particular crime scenario outstandingly well.) It is important to remember that not only
must the vendor’s product’s capabilities be evaluated, but also the vendor’s capabilities, which,
at times, are easily confused. For example, onsite support within four hours is an obvious
vendor capability, but pre-tuned detection models with consortium data is hard to place. Is this
a system capability or a vendor capability? (In my view, it is a vendor capability for
organisations that are not mature enough to tune or develop their own detection models.)
Furthermore, some systems require the vendor to replace the detection model on a regular
basis while other systems allow the IT users to perform this function, while other systems allow
the business users to do so. This makes comparison between products difficult. A system that
does not have “in-system detection-model tuning” or “new in-system model development”
(both are system capabilities) available to the users results in there being a need for capabilities
of “off-site model development and tuning” and “on-site model deployment” (both are possible
vendor capabilities). Vendor capability selection needs to be finalised before a service level
agreement (SLA) can be put in place.
The matrix could be used in an identical way to explore other capabilities needed. This means
this process may need to be repeated a number of times by a number of departments. For
example, architecture may go through this process to find system capabilities, procurement may
do the same to identify vendor capabilities and the business leaders may do the same for their
internal business capabilities.
Using the Scenario-How Matrix to Select Capabilities
Let us presume an organisation has used the who-what matrix to identify all the key scenarios of
concern and has completed the capability mapping exercise by studying numerous vendor’s
products. The organisation can now list all the scenarios of concern as rows (for example, third
party card fraud, internal fraud and terrorism finance). Next, the organisation can create
columns with the various system capabilities and determines whether that capability will assist
or be used in solving that crime scenario.
System Capabilities
Decision Link Analysis
Scoring Engine
Agent Tool
Scenarios
Third Party
Card (Plastic Enabler)
Fraud
Internal Fraud
Terrorism
Finance
In the above matrix the organisation has chosen certain capabilities for specific crime scenarios.
Perhaps they have chosen not to deploy all the technologies for all the scenarios (in the above
case, it is possible to do so) because of cost (vendors may charge by use case instead of by
capability), or because they are implementing in phases, and don’t have sufficient personnel to
use all the capabilities in the first phase deployment.
In many of the cases, the system capabilities need to be considered in one of numerous forms.
 Inline. This is also called real-time financial crime detection and prevention. This means
that no application (product request) or transaction (product use) is processed without
first doing a financial crime risk analysis (usually in milliseconds for transactions and
seconds for applications), and stopping or pausing the application or transaction in the
event of the score being particularly high. Inline processing is ideal (and now practical)
for almost all modern financial crime scenarios. The disadvantage is that this is usually
architecturally tricky if being added to legacy systems, and the technology required
(particularly processing power for the scoring engine and decision agent) can be
expensive in larger organisations.
 Online, which is also called near-real-time financial crime detection. In this case,
financial crime risk analysis is done in parallel, or directly after, an application or
transaction. The disadvantage is that the scenario can be detected but not prevented,
because by the time the high risk score is seen, the application or transaction may well
be successfully completed. Since many transactions cannot be reversed, the potential
for loss is greater than with inline processing.
 Batch (or bulk) processing. Because many legacy systems cannot handle inline or online
processing, nightly batch feeds of the day’s applications or transactions are scored. By
the time the scores reach a fraud analyst or investigator, 12 to 24 hours have passed.
This is far from ideal in the modern financial environment, but is often the cheapest of all
the methods of risk scoring (because it is often architecturally easy, and processing
power during off-peak times is readily available at little extra cost).
 Scheduled offline processing. This is really the same as batch processing, but is different
in the work that is done. Batch processing is the processing of input feeds that could be
done inline or online, but for whatever reason, is rather done in bulk. Offline processing
is regular work internal to the financial crime risk management system that takes too
long to be done as and when a user needs it. For example, a nightly file of transactions
needing scoring would be “batch processing”, but updating business intelligence
statistics (and producing the related standard reports) would be “scheduled offline
processing”. The distinction is not necessarily important, but worth understanding.
 Ad hoc offline processing. In this case, a user requests some function, such a complex
report, that cannot be done at the time of request because of the availability of system
resources (or the users know it will take a long time and don’t want to wait at the user
interface, they want the result by email when it is ready). The work goes into a queue
for processing when the system is available.
As an example to highlight the differences between the last three categories, consider the
arrival of a sanctions list delta to a financial crime detection platform (new names need to be
added to the existing list, and checks against the delta are needed). The crime risk management
system is now required to check all the existing customers against new entries in the watch list.
This is ad hoc offline processing. This is because the delta file is, in effect, an event that starts
the offline process of checking all existing customers against the delta file. It is ad hoc because
it is not scheduled but rather triggered by the event of the file arriving. (If the delta file was
processed line by line as an input file against the customers, then it would be considered a batch
process, not an offline process. This is because the delta file is being processed “in batch”
rather than the existing customers database being processed against a list.) Note, however,
that process of adding the delta file to the existing list in the system would be a (very small)
batch process.
Financial Crime System
Process: Check Master Customer List

Customers
Against Customer 1
Sanctions List Customer 2
Delta Customer 3
Customer 4
(Ad hoc Offline
Process
Triggered by
Event: “File
Arrival:
Sanctions List Delta Sanctions List Process: Check
Delta”) All Customers
Person X Against Master
Person Y Sanctions List
Person Z
(Scheduled
Offline Process
Triggered by
Yearly
Schedule)
Process: Add
Delta File to
Master
Sanctions List Master Sanctions List
(Batch Process Person A

Triggered by Person B
Event: “File Person C
Arrival: Person D
Sanctions List
Delta”)
The above diagram shows a Sanctions List Delta file arriving in the system. This triggers an ad
hoc offline process, and when complete, a batch process. There may also be a scheduled offline
process where the system rechecks all customers against the Master Sanctions List yearly.
These categories are important and must be considered. Let us consider the following to see
why they need to be included in crime risk management.
Risk Scoring Capabilities

Scheduled Ad hoc
Inline Online Batch
Offline Offline
Scenarios
Friendly
Debit Card
Fraud
Third Party
Remote Banking
Fraud
First Party
Loan Application
Fraud
Syndicate
Identification
In this case a scenario-how matrix was formed for a specific capability (risk scoring). The
organisation has identified four concerns: three crime scenarios developed from their who-what
matrices, as well as one use case (namely, syndicate identification). (Notice how the scenario-
how matrix was extended not only for crime scenarios but also for use cases in this example.
Where possible, it is better to separate use cases and crime scenarios into separate matrices
because use cases typically address a group of crime scenarios—but it is not necessary to create
separate matrices.) The business can now evaluate the pros and cons of one system capability
solving their four concerns using five different techniques. (All the examples in this white paper
are entirely hypothetical. They do not relate to any particular institution or any real life
situation.)
The first step will be to cross off capabilities that simply do not apply. Fraud risk scoring is never
done offline, perhaps with the exception of retro-scoring, which I consider a different system
capability (at night, rescoring what was scored during the day, given the new information the
system learned over the last 24 hours). For this reason, one can cross out the far end blocks, as
indicated.
The organisation can now work through each uncrossed block in turn. For example, the
organisation may find that inline or online scoring for friendly debit card fraud (abuse of debit
cards by friends and family members) is going to cost the business $100,000 p.a., while batch
scoring is going to cost $10,000 p.a.. Perhaps the current risk to the business is $5,000 p.a. and
estimated future risk over the next 10 years is $70,000. The business can then decide to put in
batch scoring, leaving financial resources available for the other scenarios.
Now, third party remote banking fraud (that is, defrauding of the bank and its customers by
third parties using channels such as internet banking) might be costing the financial institution
$300,000 p.a., and its customers $900,000 p.a.. Perhaps inline scoring will cost $400,000, online
scoring will cost $250,000, and batch scoring $30,000. The organisation can now justify inline
fraud risk scoring for third party remote banking fraud. (Depending on the vendor and the
enterprise’s architecture, this may enable the organisation, at the same cost, to implement risk
scoring on all channels for just a little bit more.)
Again, the same exercise can be done for the first party loan application fraud. For the purposes
of clarifying the extensibility of the use of the matrix, one may evaluate risks associated with
using the various technologies. For example, one may find using inline prevention reduces fraud
by 85%, using online detection reduces fraud 80% and batch detection reduces fraud 60%. (The
reduction would be different because in the time lost between issuing the customer with a
financial product and the detection of the fraud, fraud could have been committed.) The matrix
can then again be used to calculate costs (as done previously), and this compared to the
potential savings.
Lastly, the use case of syndicate identification can be considered. Inline identification would
imply that the system would identify a syndicate from patterns of incoming data in real time,
and block applications from that newly detected syndicate. (One would probably need to
develop one’s own system to do this, this is not a commonly available system capability as at
2011.) More likely, this would be done offline. Users would select groups of data for ad hoc
detection, or perhaps nightly scans of the day’s data would be scheduled.
Risk Scoring Capabilities

Scheduled Ad hoc
Inline Online Batch
Offline Offline
Scenarios
Friendly
Not Not
Debit Card fi na nci a l l y vi a bl e fi na nci a l l y vi a bl e
Fi na nci a l l y vi a bl e
Fraud
Third Party Fi na nci a l l y vi a bl e
Mos t i mmedi a te Ea s y a nd chea p but
Remote Banking cons i deri ng
fi na nci a l benefi t i neffective
Fraud reputation ri s k
First Party
Ta rget fra ud Si gni fi ca nt reduction Chea p a nd
Loan Application reduction rea ched pos s i bl e pa rtia l l y effective
Fraud
Ava i l a bl e from Ava i l a bl e but Ava i l a bl e on our

Syndicate Requi res expens i ve Requi res expens i ve
vendor X but very requi res a nother exi s ting s ys tem a t no
Identification cus tom devel opment cus tom devel opment
expens i ve vendor i n l a nds ca pe extra cos t
The matrix can thus be used for Yes/No decisions or more complex decision making.
Testing Vendor and Technology Decisions with Traditional Tools
To demonstrate how traditional tools may be used as part of the crime risk management
process, a sequence diagram will be used as an example to show that they can help verify the
chosen system capabilities. This section uses a hypothetical selection of technologies (not one I
necessarily recommend) that an organisation may derive by using the financial crime who-what
matrix as a brainstorming tool.
In this case I will assume the retail banking institution has a payments management system
requiring a fraud risk decision on each monetary transaction it processes (I will assume non-
monetary transactions such as balance enquiries are out of scope, and non-monetary events,
such as a customer address change, are also out of scope). Assume one is adding protection to
the automatic teller machine (ATM) channel, but also wanting multi-channel protection
(ensuring that a sequence of suspicious events across different channels does not occur). The
institution also needs custom rules to change on the fly, for example, if they get a tipoff of a
syndicate in an area, they need to manually adjust the risk score for ATMs in that particular
area. A decision engine will be required that makes allow, allow-and-refer or decline decisions.
Finally, an alert manager or case manager with a user interface is needed to triage and
investigate suspicious transactions.
By putting all these components into a sequence diagram, the organisation is able to see how
they need to interconnect, what data is likely to be needed for interfaces, and whether any key
capabilities are missing. Furthermore, this helps with vendor selection. Those components that
are closely coupled should ideally be sought from a single vendor.
Each component or application will need a detailed description of its capabilities and
responsibilities. While an organisation needs to understand its ideal requirements, it is unlikely
that a vendor or set of vendor will perfectly match the specification—as such, flexibility is
required. For the purposes of this example, the below should suffice to clarify the highly
simplified, hypothetical sequence diagram.
 Payments Manager: component responsible for processing all transactions.

 Enterprise Fraud Manager: component responsible for coordinating all real-time
transaction financial crime risk management activities.
 Channel Scoring Engine: component that evaluates the risk of an ATM transaction given
the specific channel data; the output is a percentage from 0.01% to 99.9% (probability of
a crime being committed).
 Multi-Channel Scoring Engine: component that evaluates the risk of any transaction
given a customer’s profile and cross-channel activity; the output is a percentage from
0.01% to 99.9%.
 Risk Adjustment Rules Engine: component that allows adjustment of scores produced by
the scoring engines based on day-to-day risk factors and tipoffs (for example, the crime
risk probability, calculated in the previous steps, may be raised 10% if the transaction
occurred in an area where skimming criminals are known to be operating on a certain
day based on a tipoff).
 Decision Agent: component that, based on the (possibly combined and adjusted) scores,
makes a decision to allow, allow-and-refer or decline-and-refer a transaction.
 Crime Case Manager: component that allows triage, case management and link analysis.
Example: Using the Matrix to Determine Data Requirements for a Set of Scenarios
Here is an example of how the matrix may be used to identify high-level data requirements for
the particular scenario of sanctions screening within a bank. The generic crime risk matrix is
used to identify the requirement as follows.
Compliance Fraud
What
Relationship Party Party Relationship Party Party
Who Initiation Status Activity Initiation Status Activity
Screening Monitoring Monitoring Screening Monitoring Monitoring
Organisation
Internal
Employee
01 02
On On SWIFT event or
First Party origination/KYC origination or
event sanctions list delta
External
03
Third Party On SWIFT event
As one can see, the scope includes monitoring potential clients as they apply for new financial
products (“on origination/KYC event”, scenario ). Thus a complex event engine might trigger a
01
fraud check in an event-driven architecture (EDA), or all the originating systems (or all Know-
Your-Customer, KYC systems) might need to be updated to call a sanctions screening service
operation in a service-orientated architecture (SOA). The organisation would then list its
categories of data, and list the specific high-level data requirements per category. For
simplicity, I will use only the categories of transient and master data. For scenario , a 01
hypothetical bank may arrive at the following requirements.
 Transient: the KYC system must pass the new customer details to the crime risk
platform.
 Master: the crime risk platform needs the latest sanctions lists.
This obviously depends on the organisation’s classification system and own data architecture.
Scenario in the matrix is triggered as indicated: “on SWIFT event or origination or sanctions
02
list delta”. One can then examine each of these three triggering events for this scenario.
 In the case of a SWIFT (Society for Worldwide Interbank Financial Telecommunication)

transaction (for example, an customer does an international money transfer), the
following is needed to check the customer during each transaction. (Notice that this is
not anti-money-laundering, AML, which monitors the transaction itself. Such AML
checking would belong in the scenario to the right, i.e., one square to the right of this
scenario in the above matrix.)
o Transient: the transaction system must pass the existing customer ID to the crime
risk platform.
o Master: the crime risk platform needs the latest sanctions lists and the customer
database.
 For the case of origination (for example, an existing customer opens a secondary
account), the same as the above event is needed.
 Where a sanctions list delta arrives, the following is needed for this event.
o Transient: the additions to the sanctions list that is already in the crime risk
platform.
o Master: the crime risk platform needs the existing customer database.
In scenario the bank is required to check the details of the person being paid by the bank’s
03
customer. For example, Person A is the bank’s customer, transferring money to Person B.
Person B is not a customer of the bank, but may be a known terrorist on the sanctions list. As
such, the details of Person B need to be checked, giving one the following data requirements.
 Transient: the transaction system must pass the counterparty’s name and country to the
crime risk platform.
 Master: the crime risk platform needs the latest sanctions lists.
Conclusion
The who-what matrix and the scenario-how matrix can assist an enterprise in managing risk. It
provides a tool for developing and selecting capabilities that deal with identified crime
scenarios. Together with other traditional tools, it can help an organisation reduce crime risk.
Summary
By using who-what diagrams, organisations are able to classify and clearly understand their
current and future crime and compliance risks. This paper outlines a conceptual framework and
provides a financial crime risk classification tool that helps an organisation identify and name
crime scenarios. It also provides a method that can assist leaders in organisations to select
business, system and vendor capabilities to address the identified risks.
The author of this white paper, an IT architect, can be reached by fax on +27 86 210 8105. The author asserts that
this is an original work, and that using who-what matrices in this way for financial crime solutions is, to the best of
his knowledge, an original and unpublished idea. This paper was written in the author’s own time and does not
reflect the views, opinions or methods of his employer.
Third Edition (March, 2011), Revised (April, 2011)
Changes since the second edition:

 restructured the generic who-what matrix into two slightly different views (compliance
and fraud at the top level or at the secondary level)
 added mention that this is a tool for understanding and solving problems, not presenting
the solutions to stakeholders
 added example questions for brainstorming
 clarified sequence diagram (during April revision).
Second Edition (February, 2011)
Changes since the first edition:

 clarified the difference between offline and batch processing
 minor wording changes throughout the document
 added the example of using the matrix for sanctions screening data requirements.
If this text-searchable edition is not displaying or printing correctly, please download the latest
printable edition at:
http://www.scribd.com/doc/47982487/Financial-Crime-Risk-Conceptual-Framework-Printable
The latest edition of this document is hosted at:
http://www.scribd.com/doc/47778666/Financial-Crime-Risk-Conceptual-Framework
Source for websequencediagrams.com
participant "Payments\nManager" as Bank

participant "Enterprise Fraud\nManager" as EFM
participant "Channel Scoring\nEngine" as Chan
participant "Multi-Channel\nScoring Engine" as MCS
participant "Risk Adjustment\nRules Engine" as Rules
participant "Decision\nAgent" as DA
participant "Crime\nCase Manager" as Case
Bank->EFM: Transaction\nPermission Request
EFM->Chan: First Score\nRequest
EFM->MCS: Second Score\nRequest
Chan-->EFM: Crime Risk\nProbability 1
MCS-->EFM: Crime Risk\nProbability 2
EFM->Rules: Probability Adjustment\nRequest
Rules-->EFM: Final Risk\nProbability
EFM->DA: Decision Request
DA-->EFM: Final Decision
EFM-->Bank: Allow or Decline Decision
EFM->Case: Create Alert\n(if High Risk)

Financial Crime Risk Conceptual Framework

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Financial Crime Risk Conceptual Framework

Uploaded by

Copyright:

Available Formats

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK

A financial crime classification tool for developing financial crime solutions

This white paper presents a conceptual framework to assist in the

Copyright © 2011, Michael Gallias

Revision: 17 April, 2011

Up to one full page of this white paper may be

Using the Matrix for Identifying Financial Crime Scenarios ___________________ 3

Using the Matrix for Identifying Financial Crime Scenarios

Understanding the Who-What Matrix

The High-Level Retail Financial Crime Who-What Matrix

The Generic Crime Who-What Matrix

Relationship Initiation Party Status Party Activity

Who Compliance Fraud Compliance Fraud Compliance Fraud

The following is an equivalent.

What Regulatory Relationship Party Party

Relationship Party Party

Orga ni s a tion mi s s es the

Empl oyee i l l ega l l y Empl oyee col l udes to gra nt

Cus tomer a ppea rs on

Terrori s t tri cks cus tomer Cus tomer ha s been

Crimes perpetrated by the organisation itself:

Crimes perpetrated by an employee in the organisation:

Crimes perpetrated by a customer of the organisation:

Crimes perpetrated by a third party:

Example: Using the Matrix for Nomenclature

Adapting the Who-What Matrix for Solving Specific Crimes

Identifying Risks and Brainstorming for Solutions by Product

Product Use Fraud

Product Use Fraud

 Who is able to commit the crime?

Credit Card Use Fraud (Channel) Online Mobile

Identifying Risks and Brainstorming for Solutions by Channel

Channel Fraud Online Mobile

Primary Card Holder

Secondary Card Holder

Unofficial Card Sharer

Channel Fraud Online Mobile

Secondary Card Holder

Unofficial Card Sharer

Using the Matrix for Solving Financial Crime Scenarios

but will focus primarily on the system capabilities.

Determining Needed Capabilities

Excursus: An Argument for Developing Business Capability By Studying System Capability

Using the Who-What Matrix to Select Capabilities

Credit Card Use Fraud (Channel) Online Mobile

sis omise lysis rio

Using the Scenario-How Matrix to Select Capabilities

Financial Crime System

Process: Check Master Customer List

(Batch Process Person A

Risk Scoring Capabilities

Risk Scoring Capabilities

Ava i l a bl e from Ava i l a bl e but Ava i l a bl e on our

Testing Vendor and Technology Decisions with Traditional Tools

 Payments Manager: component responsible for processing all transactions.

Third Party On SWIFT event

hypothetical bank may arrive at the following requirements.

 In the case of a SWIFT (Society for Worldwide Interbank Financial Telecommunication)

Third Edition (March, 2011), Revised (April, 2011)

Changes since the second edition:

Second Edition (February, 2011)

Changes since the first edition:

The latest edition of this document is hosted at:

Source for websequencediagrams.com