Financial Crime Risk Conceptual Framework

27
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. __________________________

description

A conceptual framework to assist in the identification of crime risk, as well as associated business and system capabilities to control crime.

Transcript of Financial Crime Risk Conceptual Framework

Page 1: 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.

__________________________

Page 2: Financial Crime Risk Conceptual Framework

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

Page 3: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 3

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

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.

Violations of

Regulatory

Compliance

Money

Laundering

Terrorism

Finance

Product

Application Fraud

Product

Use Fraud

Rogue Organisation

Rogue Employee

First Party

Third Party

Inte

rnal

Extern

al

What

Who

Page 4: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 4

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.

Page 5: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 5

When the financial crime matrix used outside of financial industry, the matrix can be more generically depicted as follows.

The following is an equivalent.

The first three columns can sometimes be combined for the sake of simplicity.

Compliance Fraud Compliance Fraud Compliance Fraud

Organisation

Employee

First Party

Third Party

What

Who

Inte

rnal

Extern

al

Relationship Initiation

Screening

Party Status

Monitoring

Party Activity

Monitoring

Relationship

Initiation

Screening

Party

Status

Monitoring

Party

Activity

Monitoring

Relationship

Initiation

Screening

Party

Status

Monitoring

Party

Activity

Monitoring

Organisation

Employee

First Party

Third PartyIn

tern

alExte

rnal

What

Who

FraudCompliance

Regulatory

Compliance

Management

Relationship

Initiation

Screening

Party

Status

Monitoring

Party

Activity

Monitoring

Organisation

Employee

First Party

Third Party

What

Who

Inte

rnal

Extern

al

Page 6: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 6

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.

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

Regulatory Compliance

Management

Relationship

Initiation

Screening for

Fraud

Party

Status

Monitoring for

Fraud

Party

Activity

Monitoring for

Fraud

OrganisationOrganisation misses the

deadl ine for green energy

laws

N/AOrganisation appears on a

watch l i s tN/A

EmployeeEmployee i l legal ly

views and shares

account detai l s

Prospective employee is

on pol ice l i s t

Employee appears on

industry watch l i s t

Employee col ludes to grant

appl ication of product to

fraudster

First PartyCustomer violates loca l

withdrawal law

Prospective customer is on

industry black l i s t

Customer appears on

pol i tica l ly exposed

persons l i s t

Customer logs fa lse cla im

on credit card

Third PartyTerroris t tricks customer

and then receives transfer

from customer

N/A

Customer has been

transferring large sums to

newly discovered fraudster

Fraudster skims debit card

and draws money at ATM

What

Who

Inte

rnal

Extern

al

01 02 03 04

08070605

12111009

16151413

Page 7: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 7

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.

Page 8: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 8

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.

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.

Violations of

Regulatory

Compliance

Money

Laundering

Terrorism

Finance

Product

Application Fraud

Product

Use Fraud

What

Who

Inte

rnal

Application Fraud

Rogue Organisation

Rogue Employee

First Party

Third Party

Inte

rnal

Application FraudExtern

al

Page 9: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 9

The first party fraud scenario would appear as follows in the matrix. (I shall call each block or group of blocks a “crime scenario”.)

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

Violations of

Regulatory

Compliance

Money

Laundering

Terrorism

Finance

Product

Application Fraud

Product

Use Fraud

Rogue Organisation

What

Who

Inte

rnal

Application Fraud

Rogue Employee

First Party

Third Party

Inte

rnal

Extern

al

Application Fraud

Violations of

Regulatory

Compliance

Money

Laundering

Terrorism

Finance

Product

Application Fraud

Product

Use Fraud

Rogue Organisation

Rogue Employee

What

Who

Inte

rnal

Extern

al

First Party FraudFirst Party

Third Party

Extern

al

First Party Fraud

Page 10: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 10

words, the new matrix is a “zoom in” of the very bottom far right block of the main matrix first presented.)

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.

Violations of

Regulatory

Compliance

Money

Laundering

Terrorism

Finance

Product

Application Fraud

Product

Use Fraud

Rogue Organisation

Rogue Employee

First Party

Third Party

Inte

rnal

Extern

al

What

Who

Credit Card Debit Card Gift Card Current Account Loan Account

Stranger

Friend

Family

Member

Business Partner

Automated Software

Product Use Fraud

External Third Parties

Extern

al

Credit Card Debit Card Gift Card Current Account Loan Account

Stranger

Friend

Family

Member

Business Partner

Automated Software

Product Use Fraud

External Third Parties

Extern

al

Page 11: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 11

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.

Page 12: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 12

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.

Online

(Internet

Shopping)

Mobile

(Internet Phone

Shopping)

IVR Branch ATM

Individual

Colluder with

Staff

Colluder with

First Party

Mob

Syndicate

Credit Card Use Fraud (Channel)

Strangers

Extern

al

Online

(Internet

Shopping)

Mobile

(Internet Phone

Shopping)

IVR Branch ATM

Primary Card Holder

Secondary Card Holder

Unofficial Card Sharer

Channel Fraud

External First Parties

Extern

al

Page 13: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 13

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.

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).

Online

(Internet

Shopping)

Mobile

(Internet Phone

Shopping)

IVR Branch ATM

Channel Fraud

External First Parties

Extern

al

First Party

Multi-Channel FraudPrimary Card Holder

Secondary Card Holder

Unofficial Card Sharer

Extern

al

First Party

Multi-Channel Fraud

Page 14: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 14

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.

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.

Other Vendor CapabilitiesBusiness Capabilities System Capabilities System Vendor Capabilities

Page 15: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 15

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.

Page 16: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 16

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.

Online

(Internet

Shopping)

Mobile

(Internet Phone

Shopping)

IVR Branch ATM

Individual

Colluder with

Staff

Colluder with

First Party

Mob

Credit Card Use Fraud (Channel)

Strangers

Extern

al

* Link Analysis

* Mass Compromise

Analysis

* Real-time Scenario

Solving* SimulationSyndicate

Extern

al

* Link Analysis

* Mass Compromise

Analysis

* Real-time Scenario

Solving* Simulation

Page 17: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 17

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.

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

System Capabilities

Scenarios

Scoring EngineDecision

Agent

Link Analysis

Tool

Third Party

Card (Plastic Enabler)

Fraud

Internal Fraud

Terrorism

Finance

Page 18: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 18

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

Page 19: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 19

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.

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.

Sanctions List Delta

Person XPerson YPerson Z

Master Sanctions List

Person APerson BPerson CPerson D

Process: Add Delta File to

Master Sanctions List

(Batch ProcessTriggered by Event: “File

Arrival: Sanctions List

Delta”)

Master Customer List

Customer 1Customer 2Customer 3Customer 4

Process: Check Customers

Against Sanctions List

Delta

(Ad hoc Offline Process

Triggered by Event: “File

Arrival: Sanctions List

Delta”)

Process: Check All Customers

Against Master Sanctions List

(ScheduledOffline Process

Triggered by Yearly

Schedule)

Financial Crime System

Page 20: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 20

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

Risk Scoring Capabilities

Scenarios

Inline Online BatchScheduled

Offline

Ad hoc

Offline

Friendly

Debit Card

Fraud

Third Party

Remote Banking

Fraud

First Party

Loan Application

Fraud

Syndicate

Identification

Page 21: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 21

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.

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.

Risk Scoring Capabilities

Scenarios

Inline Online BatchScheduled

Offline

Ad hoc

Offline

Friendly

Debit Card

Fraud

Not

financia l ly viable

Not

financia l ly viableFinancia l ly viable

Third Party

Remote Banking

Fraud

Financia l ly viable

cons idering

reputation risk

Most immediate

financia l benefi t

Easy and cheap but

ineffective

First Party

Loan Application

Fraud

Target fraud

reduction reached

Signi ficant reduction

poss ible

Cheap and

partia l ly effective

Syndicate

Identification

Requires expens ive

custom development

Requires expens ive

custom development

Avai lable from

vendor X but very

expens ive

Avai lable but

requires another

vendor in landscape

Avai lable on our

exis ting system at no

extra cost

Page 22: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 22

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.

Page 23: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 23

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.

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 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 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 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

Relationship

Initiation

Screening

Party

Status

Monitoring

Party

Activity

Monitoring

Relationship

Initiation

Screening

Party

Status

Monitoring

Party

Activity

Monitoring

Organisation

Employee

First Party

On

origination/KYC

event

On SWIFT event or

origination or

sanctions list delta

Third Party On SWIFT event

What

Who

Compliance Fraud

Inte

rnal

Extern

al

01 02

03

01

01

02

Page 24: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 24

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 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.

03

Page 25: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 25

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.

Page 26: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 26

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.

Page 27: Financial Crime Risk Conceptual Framework

A FINANCIAL CRIME RISK CONCEPTUAL FRAMEWORK 27

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)