Bank Risk Management Case Study

Martin Keen
Redpaper Simon Darby

Rashmi Kaushik
Paul Leonhirth
Robert Molloy
Jeffrey Skinner
Robert Snider
Case Study: Risk Management Banking

Scenario
This IBM® Redpaper™ publication is one in a series of service-oriented architecture (SOA)

papers that feature a case study that involves a fictitious company called JKHL Enterprises
(JKHLE). In this paper, we focus on the banking division of JKHLE, JKHL Bank.
In this paper, we focus on the integrated risk management aspects of retail banking. The
scenario provides one specific example within retail banking, the Account Originations
process, out of a broad set of integrated risk management scenarios. Within Account
Originations, we highlight regulatory compliance, fraud risk, and credit risk management
procedures and best practices.
© Copyright IBM Corp. 2009. All rights reserved. ibm.com/redbooks 1

IBM Banking Industry Framework
IBM provides a unified banking framework that spans the enterprise and software foundation
for end-to-end banking solutions. The IBM Banking Industry Framework is the strategic
middleware foundation for solutions. IBM Banking Industry Framework domains provide
software, industry extensions, and accelerators to address specific banking industry needs,
as illustrated in Figure 1:
򐂰 The payments and securities domain provides the middleware tooling to help you
progressively transform your payments operations to become more flexible and efficient.
򐂰 The integrated risk management domain supports taking a holistic approach to managing
financial risk, operational and IT risk, financial crimes, and compliance.
򐂰 The customer care and insight domain helps you build a foundation for creating a single
view of the customer and enabling more effective and efficient sales and service.
򐂰 The core banking transformation domain allows you to modernize existing applications
that support core banking functions while aligning with the changing needs of the
business.
Figure 1 IBM Banking Industry Framework
The IBM Banking Industry Framework provides the following benefits:

򐂰 Enables integration of information and processes across a bank’s silos that can lead to
greater efficiencies, better customer services, and reduced data requirements.
򐂰 Uses software technologies to solve different business problems ranging from improved
customer service to better risk management.
򐂰 Maximizes re-use of software assets.
򐂰 Improves solution deployment time with foundational and module-specific software
extensions and accelerators.
2 Case Study: Risk Management Banking Scenario

The case study in this paper focuses on the integrated risk management domain from the
IBM Banking Industry Framework. For information about the other domains from the IBM
Banking Industry Framework refer to the following resources:
򐂰 The customer care and insight and core banking transformation domains are described in
Case Study: SOA Banking Business Pattern, REDP-4467.
򐂰 The payments and securities domain is described in Case Study: Corporate Payments
Banking Scenario, REDP-4544
Risk management trends in the banking sector

This section examines the current risk management trends in the banking sector, and
presents the case for taking an integrated approach to address risk.
An increased focus on credit risk, fraud, and compliance for retail banks
The 2008 credit crisis showed a fundamental breakdown in risk management exposing retail
banking. This was due to a number of factors, including:
򐂰 Ample credit availability
򐂰 Weakness in risk culture
򐂰 Lack of executive-level risk governance and oversight
򐂰 Lack of integration and complexity
The credit crisis and rising financial crimes from the digital economy resulted in cross border
coordinated regulatory and agency oversight. Growth in the digital economy has seen a
proportional rise in all categories of fraud over the recent decade:
򐂰 A significant rise in mortgage fraud during the real estate bubble arising from easy credit.
򐂰 The post-2008 crisis saw the emergence of fraud in the application of federal stimulus and
home foreclosures.
򐂰 The emergence of an underground economy monetizing stolen identities, illegal
transactions, phishing, and other financial crimes are causing losses in retail banking.
The changing compliance landscape

The changing compliance landscape calls for a more consistent and automated approach
across the enterprise:
򐂰 At the time of writing, there were 4,266 new regulations in the pipeline.
򐂰 There are over 10,000 regulations worldwide.
򐂰 Over $1.1 trillion is spent to comply with US federal requirements.
Case Study: Risk Management Banking Scenario 3

The need for improved fraud risk analytics within retail banking
Organized crime in the digital economy through social engineering and multi-channel fraud
are driving the need for better risk analytical tools and centralized fraud management1:
򐂰 Over $5 trillion in stimulus spending by governments is an unprecedented opportunity for
fraud. Fraud Research firm Kroll estimates over $500 million as loss due to fraud.
򐂰 Data from survey conducted by Association of Finance Professionals shows payments
fraud in 2009 is on the increase compared to prior years.
򐂰 Increasing credit/debit card fraud, mortgage fraud, identity theft, and information breaches
have become critical factors for banks to consider more robust analytical tools to prevent
losses.
The extent of US financial fraud, as determined by the US Financial Crimes Enforcement

Network, is shown in Figure 2.
US financial fraud
Number of suspicious-activity reports filed, '000 800
Other
Consumer-loan fraud
False statement
Identity theft
Credit/debit-card fraud
600
Mortgage fraud
Check fraud
400
200
Money laundering
0
1997 98 99 2000 01 02 03 04 05 06 07 08
Source: US Financial Crimes Enforcement Network
Figure 2 US financial fraud
1
Source for the preceeding facts in this section: Kroll, Association of Finance Professionals and US Financial
Crimes Enforcement Network

The need for credit risk analytics to be implemented holistically
Credit risk management merits heightened attention in a credit-starved environment since
banks must use this process to prevent deterioration in asset quality. There is a need for
credit risk analytics to be implemented holistically in the organization to ensure
comprehensiveness. For example:
򐂰 At a risk COE level, to analyze bank’s risk exposure as a whole.
򐂰 At an individual business process level, such as Account Originations, to ensure credit
worthiness of a bank’s customers.
򐂰 At underwriting management level, to refine lending guidelines, processes, and
procedures based on a bank’s performance.
Taking an integrated approach to address regulatory compliance, fraud, and

credit risk
Consider taking an integrated approach to prevent loss, reduce costs, protect revenue, and
improve customer experience:
򐂰 Mitigate risk with improved analytics
Integration addresses the increasing sophistication of cross channel attacks and the
multiplying influence of insider collusion.
򐂰 Do more with automation
Thin integration of existing systems and processes provides the quickest time to value by
building on existing capabilities and adapting to changing regulations.
򐂰 Collaborate to sell more, safely
Integration enables better interaction and collaboration with business disciplines to
optimize performance.
򐂰 Improve customer experience with better insight and systemize your decisions for optimal
results
Integration of new analytical capabilities into existing systems offers better customer and
risk insight, lowering risk exposure. Automated decision management allows
standardization and optimization within business processes, reducing errors and risk, and
providing a more consistent customer experience.
JKHL Bank in the banking industry

JKHL Bank is a fictitious tier 2 bank that over the last several years acquired five smaller
regional banks to create a broader geographic presence. JKHL Bank identified several SOA
initiatives intended to improve growth, reduce costs, reduce operational risks, and improve
customer experience.
The case study that we describe in this paper includes the following key actors and roles:
򐂰 Thomas Arnold, Chief Operating Officer, JKHL Bank
򐂰 Sandy Osbourne-Archer, Chief Technical Architect, JKHL Bank
򐂰 Geoffrey Carroll, Banking Industry Architect, IBM
In a conversation with Sandy Osbourne-Archer, the JKHL Bank’s chief operating officer,
Thomas Arnold, outlines the company objectives and business requirements. Thomas and
Sandy agree that in recent years, JKHL Bank has become a leader in retail banking and has

made several improvements in the area of customer care and insight, which has contributed
hugely to JKHL Bank’s success. Thomas tells Sandy that recent changes in the banking
sector has turned his attention to the risk management area.
Thomas has the following business objectives relating to risk management:

򐂰 Decrease losses due to unmanaged risk.
JKHL Bank risk management processes are by and large viable. However, it is the lack of
ability to execute and change complex decisions and drive process swiftly that is crippling
the bank.
򐂰 Control and reduce the high rates of fraud and identity abuse across the business
channels, so the bank does not lose customers as a result of negative experiences.
JKHL Bank is experiencing increasing losses to fraud. This fraud is occurring in attempts
to obtain credit by new customers through the Web and in branches. Fraud is also present
with existing customers defaulting in a variety of ways.
򐂰 Obtain better insight into customer credit risk.
JKHL Bank's customers have not been immune to the effects of the economic crisis. The
situation and financial standing of many of JKHL Bank’s customers have changed.
򐂰 Increase focus on regulatory compliance as a result of doing business over newer
channels such as online and mobile.
򐂰 Improve risk transparency as well as advanced modeling and analytical techniques.
򐂰 Protect JKHL Bank's reputation and brand at all costs.
In order to make their banking operations more profitable and achieve these business
objectives, Thomas and Sandy agree to recruit IBM to analyze its existing business
processes and provide recommendations for a business transformation. This IBM team is led
by Banking Industry Architect Geoffrey Carroll.
Business process modeling

Sandy Osbourne-Archer and Thomas Arnold ask Geoffrey and his team from IBM to start by
analyzing the Account Originations business process. Sandy justifies why the Account
Originations process is a good place to start:
򐂰 The Account Originations process has turned out to be one of the highest cost bases
resulting from fraud losses and insufficient credit exposure analysis.
򐂰 Risk management solutions for the Account Originations process impacts multiple lines of
business, hence making it a priority for JKHL Bank.
򐂰 This is an opportunity to reuse and centralize the risk management solution across
different account origination processes (consumer loans, mortgages, checking and
savings, credit cards, and so forth), providing a high return on investment.

Observing the existing business
Geoffrey Carroll, the banking industry architect from IBM, performs a series of interviews with
key JKHL Bank stakeholders to understand the current Account Originations process. As a
result, Geoffrey is able to note the common pain points relating to risk management in the
Account Originations process.
򐂰 JKHL Bank
– The current analysis of customer information during account origination is ineffective
(for loans, mortgages, cards, checking and savings), leading to inaccuracies in
identifying potentially fraudulent applicants.
– An inability to confirm that all identity and fraud checks have been completed, since
tasks are currently manually and are dependent on account processors.
– The bank needs a more effective way to isolate the most suspicious applicants and
reduce number of manual investigations and false positives.
– With newer business channels such as online and mobile, fraud opportunity is much
greater, leading to increased regulatory compliance needs.
– The post-funding audit process is lengthy and time consuming due to missing
compliance documentation.
– There is not a complete view of a customer’s associations with different account types,
leading to higher credit risk.
– The bank is at a risk of losing business as a result of negative customer experiences.
򐂰 Victims of fraud
– Identity theft is only known after execution of a transaction.
– Customers of the bank who have suffered from fraud are concerned about the bank’s
ability to protect their interest.
򐂰 JKHL Bank’s IT systems
– A limitation in enterprise data and analytical tools has forced the focus on transactional
fraud, rather than preventive techniques.
– Current tools support only simple fuzzy logic matches, leading to inaccuracies in
– Business analysts and policy makers lack tools to make direct policy changes. All
changes have to go to the IT department, leading to delays in event fulfilment.
– Manual intervention is prevalent in automated parts of the Account Originations
process for simple-to-critical decision making.
Analyzing the mortgage origination process

The specific Account Originations process that Geoffrey and his team examine is the process
for creating mortgage accounts: the Mortgage Origination process. Geoffrey analyzes the
internet channel for mortgage origination.
Note: Although the mortgage origination process is analyzed in this section, the suggested
refinements are applicable to any Account Originations process.

Geoffrey notes that the existing mortgage origination process in place at JKHL Bank already
has some risk management built into it. Geoffrey outlines how to refine the process further to
make it more effective and comprehensive, using proven IBM’s business expertise,
methodologies, and solutions.
Mortgage origination process summary

The high level view of the mortgage origination process is shown in Figure 3.
Loan application is Setup Loan involves

submitted via online verifying information
channel. Bank receives submitted by borrowers
loan application and and property info.
assigns a loan number to Then, conduct fraud
the application. The and customer risk rating
mortgage origination checks. If borrowers
process is exemplified pass the checks, then
using the online channel complete loan set up
in this workflow, and order credit reports
however, similar steps and other info for
apply for other channels Underwriting review.
such as branch, mobile Role: Loan Processor
and phone.
Bank Receives Setup Loan Text

Customer Loan
Application
Prepare for
Underwrite Closing Loan Loan
Loan Closing Funding
The underwriter receives the Loan conditions are cleared Communicate with closing
loan app from the queue. or loan is amended as agent and schedule a Contact closing agent,
Reviews all available info on needed. If borrower accepts closing date. Generate prepare wire information,
borrowers and creates loan loan offer, app is routed for closing docs, review file for obtain any pending docs to
conditions. If mismatch with drawing up docs. If loan is completion and send to satisfy loan conditions and
supporting documentation. not accepted or approved Loan Closer for funding. release funds. Send file to
The underwriter also reviews on amended terms, loan is Role: Document post funding queue for final
borrowers credit and fraud denied and routed to non- Coordinator/Loan Closer checks and storing file in
reports and determines if funded loans process. repository. ...
further investigation is Role: Loan Processor
needed. If info submitted is
sufficient to make a decision,
then the loan is
approved/denied/submitted
for counter offer.
Role: Underwriter
Figure 3 Mortgage Originations process

The Mortgage Origination process comprises of the following main processes:
򐂰 Receive Loan Application
Receive and assign a loan number to the loan application.
򐂰 Setup Loan:
Verify application information, conduct thorough compliance, fraud and credit checks.
򐂰 Underwrite Loan
Review of information by an underwriter leading to approval/decline of an account
application.
򐂰 Process Loan
Loan conditions are satisfied or loan is amended as per an underwriter’s decision.
򐂰 Draw Documents
Loan documents are generated and readied for closing.
򐂰 Fund Loan
Fund and close the loan, and send a file for post-funding audit.
Geoffrey recommends two main processes for re-engineering: Setup Loan and Underwrite
Loan.

Refined Setup Loan process
The refined setup Loan process is shown in Figure 4.
Review and
verify borrower
and co-borrower's Review and Order Credit
information is verify Report and
complete property Appraisal
information
is complete
Text
name, address, tax ids, income, assets, etc.
Conduct Mortgage
Due Diligence Text Complete Loan
Setup and Route
Text
to appropriate
underwriting
department based
on business rules
This re-engineered process now includes:

1. Regulatory Compliance Checks such as KYC scoring, id checks with govt. and
internal lists.
2. Fraud Checks including fraud scoring, electronic information checks, etc.
3. Credit Checks using credit reports, composite scores and credit risk exposure
analysis.
Key Techniques used to support the checks above are identity resolution,
relationship resolution, predictive analysis and historical data analysis. This
process can be reused in different account opening workflows ...
Figure 4 Refined Setup Loan process
Refined process summary

Geoffrey Carroll explains how the Setup Loan process has been defined and automated to
drive consistency, accountability, efficiency, and compliance:
򐂰 The borrower and property information are verified for completeness.
򐂰 Any documentation such as appraisal and credit reports are ordered up front to support
the credit and fraud checks.
򐂰 Since the application has been submitted online, thorough checks for regulatory
compliance, fraud, and credit are conducted.
򐂰 The loan is set up for review by underwriting.

Benefits from the refined process
Geoffrey explains that the refined Setup Loan process includes a new reusable sub-process
called Conduct Mortgage Due Diligence. This sub-process can serve multiple account types
beyond mortgages (such as credit cards, consumer loans, and so forth). It provides the
following benefits:
򐂰 The reusable sub-process carries out robust identity, relationship, fraud, and credit checks
early in the mortgage origination process.
򐂰 Allows for proactive identification of risks in the on-boarding process to reduce
transactional fraud.
򐂰 Provides automation, a consistent approach for exception processing, and decision
making using dynamic business rules
The Conduct Mortgage Due Diligence sub-process can be broken down into two parts: one
that addresses regulatory compliance checks, and one that addresses fraud and credit
checks.
Conduct Mortgage Due Diligence sub-process: regulatory compliance

checks
The part of the Conduct Mortgage Due Diligence sub-process that addresses regulatory
checks is shown in Figure 5.
Regulatory Compliance Checks and

predictive analysis via KYC Score
Financial Investigative
50.0% Yes Unit (FIU) to check
Check id match and/or applicant information
relationship match further and confirm
with individuals on match
OFAC, PEP, 314A
(suspected terrorist)
and internal fraud 50.0% No
lists and Generate
KYC Risk Score If match with
50.0% Yes OFAC 314A, PEP
or internal
bad list
KYC Score presents a risk score based
on borrowers information such as:
entity type (enterprise, individual,
charity org.), demographics, identity
50.0% No information.
New
customer?
If it's an existing customer, then

50.0% Yes
KYC scoring and other
regulatory compliance checks
are not needed since this is
already done on a periodic basis
50.0% No
If confirmed For PEP and 314A, IF KYC Score

match with OFAC put processing on presents high
and internal hold until risk, then conduct
bad list notification is enhanced due
received from FIU to diligence
proceed
Figure 5 Conduct Mortgage Due Diligence: regulatory compliance checks

Process summary
򐂰 For new customers, the refined business process includes regulatory compliance checks
in the Setup Loan process, prior to underwriting.
򐂰 In-depth identification checks and matches with internal and external bad lists,
relationships to individuals who pose fraud threats, or suspected terrorists.
򐂰 Includes predictive analysis through “Know Your Customer” (KYC) scoring.
򐂰 If the KYC score is high, then perform enhanced due diligence.
򐂰 If the result of any of the checks pose as high risk, then the customer information is sent to
the financial investigative unit for further investigation.

򐂰 Improved analytics using cutting edge techniques for identification, relationship, and
predictive analysis, providing JKHL Bank with early detection of risky applicants and better
control on the risk exposure.
򐂰 Increased regulatory compliance through a consistent and automated approach.
򐂰 By conducting comprehensive, automated triaging, the bank is able to focus primarily on
high risk cases, reducing time required in manual investigation.
Challenges addressed
This sub-process addresses the challenges with the existing business, as outlined by
Geoffrey Carroll in “Observing the existing business” on page 7:
򐂰 The bank needs a more effective way to isolate the most suspicious applicants and reduce
the number of manual investigations and false positives.
򐂰 With newer business channels such as online and mobile, fraud opportunity is much
greater, leading to increased regulatory compliance needs.
򐂰 An inability to confirm that all identity and fraud checks have been completed, since tasks
are currently manual and dependent on account processors.
Conduct Mortgage Due Diligence sub-process: fraud and credit checks

The part of the Conduct Mortgage Due Diligence sub-process that addresses fraud and credit
checks is shown in Figure 6.
Deny
Fraud Checks Application
Fraud Checks via Credit Checks
50.0% Yes
predictive analysis
Check electronic 50.0% Yes Fraud Investigative

information from unit Review Conduct Credit
application submission 50.0% No Exposure Analysis Text
Generate Fraud to guage impact of
(such as MAC address,
Scores for both borrowers' new
e-mail, ip address) and Confirmed
borrower and loan on the bank,
property information 50.0% No Fraud?
co-borrower based on historical
(refi frequency, pmt
history, appraisal info) Is the electronic information
information or
property info
suspect? The Credit Checks process has been enhanced to include a new
dimension of data analysis – New analytical reports and intelligence
Electronic info check holds good will be generated for underwriting to understand the performance of
only for online e-submissions. existing borrowers with similar profile (credit score range, loan
This step does not apply if the product, geography) as new applicant and come up with a risk
customer is applying in a bank rating system. This process can trigger alerts if the risk rating is not
branch. within threshold limits and lead to an amendment of loan offer, so
the account is originated to fit tighter lending guidelines.
Figure 6 Conduct Mortgage Due Diligence: fraud and credit checks

Process summary
򐂰 Generate fraud score based on predictive analysis.
򐂰 Check electronic information such as MAC, e-mail, and IP addresses for possible bad
associations.
򐂰 Route to the Fraud Investigative Unit if the information raises red flags.
򐂰 Conduct credit checks based on credit report and other documents submitted.
򐂰 Create a report based on performance of JKHL Bank’s existing borrowers with similar
profiles (such as the same geographical location, product, and credit scores) for
underwriting use.

򐂰 Automating risk checks as part of the account origination process provides tracking ability,
record retention, and consistent execution of tasks.
򐂰 Dynamic business rules-driven decisions, routing, and exception processing minimizes
manual intervention and allows for easy changes in business policies.
򐂰 Adding new data dimensions into the credit risk analysis based on the current customer
base with similar profiles provides a way to develop the bank’s own risk rating system,
triggering alerts for amendments to the loan offer (risk based pricing), which makes this an
exhaustive credit risk exposure analysis process.
Challenges addressed
This sub-process addresses the challenges with the existing business, as outlined by
Geoffrey Carroll in “Observing the existing business” on page 7:
򐂰 Current tools support only simple fuzzy logic matches, leading to inaccuracies in
򐂰 A limitation in enterprise data and analytical tools has forced the focus on transactional
fraud, rather than preventive techniques.
򐂰 Manual intervention is prevalent in automated parts of the Account Originations process
for simple-to-critical decision making.
򐂰 The post-funding audit process is lengthy and time consuming due to missing compliance
documentation.

Refined Underwrite Loan process
The second process that Geoffrey Carroll recommends be re-engineered is the Underwrite
Loan process. The refined version of this process is shown in Figure 7.
Create Loan Review Underwriter

50.0% Yes conditions Dashboard containing
borrower's fraud report,
risk ratings and credit
exposure impact and
property information
50.0% No
Is there a
discrepancy
based on
application
information
and supporting
docs?
Continue
processing by
validating
Determine loan
property liens,
pricing and
tax information,
validate loan
appraisal, etc.
product
50.0% Yes
50.0% No
All red flags

cleared and
confirmed that
property is not a
flip or involves
fraudulent
transaction?
Route to FIU for Manage Loan

further investigation Condition
Figure 7 Refined Underwrite Loan process
Refined process summary

The underwriting process is working well today overall, except that underwriters spend a lot of
time collecting information from different sources instead of actually underwriting the loan. To
improve the efficiency of this process and optimize the performance of the underwriters,
Geoffrey recommends implementing a single dashboard. This dashboard includes
information from internal sources (such as an applicant’s risk scores, applicant information,
FIU results, and so forth) combined with external sources of information (such as credit
reports, public information, and so forth). The information contained within the dashboard is
used by an underwriter:
򐂰 The underwriter receives the loan application from the review queue.
򐂰 The underwriter reviews all information submitted by the borrower, along with reports,
scores, and analysis obtained from the Mortgage Due Diligence process.

򐂰 Underwriters are now primarily focused on underwriting loans, rather than spending time
on querying systems to obtain required information for decision making.
򐂰 High risk applicants are automatically flagged, providing the underwriter with a complete
analysis to speed up decision making.
򐂰 Alerts based on business rules help underwriters determine additional investigation that
the application requires.
IBM Banking Payments Content Pack for WebSphere

Geoffrey Carroll recommends that JKHL Bank uses the IBM Banking Payments Content Pack
for WebSphere® as an accelerator to jump start the Mortgage Origination business process
modeling to make it deployment ready. The IBM Banking Payments Content Pack for
WebSphere provides out of the box business object models, process models, services
models, business vocabulary, all of which are based on banking standards (including ISO
20022, APQC, IFW, and SEPA).
Using the IBM Banking Payments Content Pack for WebSphere, Geoffrey estimates JKHL
Bank can save about 30% of the time from the business analysis, design, and development
cycle of the solution.
JKHL Bank’s technical environment

Geoffrey Carroll explains that this technical environment faces challenges with IT systems
and applications that support compliance risks, fraud risk, and credit risk management:
򐂰 Historically, a channel-based approach has lead to an overly complex data, detection, and
case management architecture.
򐂰 Business intelligence and reporting is nearly impossible.
򐂰 Transformation is difficult.
򐂰 Limits in enterprise data and analytical tools has forced the focus on transactional fraud,
rather than preventive techniques.
򐂰 Tools support only simple fuzzy logic matches, leading to inaccuracies in identifying
potentially fraudulent applicants.

Geoffrey illustrates JKHL Bank’s technical environment, as shown in Figure 8.
Channels Business Silos Core Systems Detection Case Mgmt.

DS DS
OD OD
DS DS
Branch Retail App

Deposit Case Management
DS DS
OD OD
DDA
ATM DS DS
Wealth ATM/Debit Case Management

Management
App DS DS
OD OD
Merchants
DS DS
CF
AML Case Management
Mobile DS DS
OD OD
App DS DS
Commercial
Credit Card Case Management
Online
Credit Card
Identity CM
Call Center Capital

Insider CM
Markets App
eCommerce CM
Lending Systems
Relationship
Manager
ACH/Wire CM
Figure 8 JKHL Bank's technical environment
Geoffrey then outlines JKHL Bank’s architectural principles for redesigning this solution:
򐂰 The channel architecture/presentation layer will be lightweight, with business logic held in
the middleware layer or application servers.
򐂰 The middleware layer will be the integration vehicle between applications and the standard
user interface, and will provide services that will enable those interactions.
򐂰 The solution will be service-oriented.
򐂰 Applications will be built as services or collections of services, to maximize business
flexibility and agility.
򐂰 Applications will locate services through a registry.
򐂰 Applications will interact with the SOA infrastructure according to agreed (and
documented) behavior.
򐂰 Service levels covering performance and availability will be defined and agreed by all the
stakeholders and stated in business terms
򐂰 Services will be used to access data (no direct coupling to data stores).

Core business and SOA infrastructure patterns
Geoffrey Carroll explains that a good way to define an architecture that meets JKHL Bank’s
needs is to break the solution into simple business and SOA infrastructure patterns. These
SOA patterns simplify the understanding of the overall solution from an SOA perspective.
Applying SOA patterns and leading practices makes it easier for JKHL Bank to understand
the impact of each piece of the solution and helps JKHL Bank adopt the solution in phases.
There are two distinct types of SOA patterns:

򐂰 Core business patterns
Patterns required to solve the business problem at hand. The business patterns used in
this scenario, along with the business needs they address are shown in Table 1.
򐂰 Core SOA infrastructure patterns
Patterns required to implement a comprehensive SOA-based solution and build upon a
strong SOA foundation (for example, security, management and governance of services).
The infrastructure patterns used in this scenario, along with the business needs they
address are shown in Table 2 on page 18.
Table 1 Business patterns used by JKHL Bank
Business need Business patterns and IBM Banking Industry
Framework components
Need to strengthen regulatory compliance checks: Pattern to apply: Entity Analytics pattern
򐂰 Need identity analysis to detect non-obvious borrower Products:
information based on name, address, email address, electronic 򐂰 IBM InfoSphere™ Identity Insight Solutions
information associated with loan application submission.
򐂰 Need analytical tools to detect risk borrowers that are related to
persons on internal fraud lists, OFAC, PEP or suspected terrorist
(314-A) lists.
Predictive analysis for KYC and fraud scores to limit fraud and Pattern to apply: Risk Analytics pattern
compliance risk exposure. Products:
Need improved analytics for credit risk exposure in account 򐂰 IBM Cognos® Banking Risk Performance –
origination: for credit risk exposure analysis, reporting and
򐂰 Need to build a more in-depth credit risk analysis within Account dashboards.
Originations using new data dimensions, reports and intelligence 򐂰 Products from SPSS, an IBM Company,
from current performance of existing borrowers with similar Norkom, Actimize, ACI, and FICO for
profiles and product needs. This will provide better insight during predictive analysis capabilities for compliance
the underwriting process. and fraud
򐂰 Need for supplemental reports and dashboards for Risk COE to
conduct a broader range of the bank’s credit risk analysis.
Need for automation of business policies in Account Pattern to apply: Business Rules Integration
Originations: and Automation pattern
Need to integrate business rules into the current Account Products:
Originations process to reduce manual processing of exceptions, 򐂰 IBM WebSphere Dynamic Business Process
increase efficiency in the decision making process, and provide more Edition
control to business analysts on policy changes, simulation, and 򐂰 IBM WebSphere ILOG Business Rules
testing. Management System
򐂰 IBM Banking Content Pack for WebSphere
Need for aggregation of information on-the-glass for FIU and Pattern to apply: Interaction and Collaboration
underwriting: using Mashups pattern
Need for a flexible dashboard that aggregates information from Products:
internal sources (identification and relationship matches, predictive 򐂰 IBM Mashup Center (comprising of Mashup
analysis scores, and customer application information) and external Builder and Data Mashup Builder).
sources (credit reports, public information, and appraisals) to make
fraud/financial investigation and underwriting more efficient.

Table 2 SOA infrastructure patterns used by JKHL Bank
Business need SOA infrastructure patterns and IBM
components
򐂰 Need for a robust SOA infrastructure for rapid, flexible Patterns to apply:
application development and to reduce costs. 򐂰 Rapid Development and Integration
(Service Creation) pattern: IBM Rational®
򐂰 Need for reuse of existing assets and services. Rose® Data Modeler, Rational Software
Architect.
򐂰 Need to secure, manage and govern services across the 򐂰 Connectivity pattern: IBM WebSphere
enterprise for an optimal operational environment and success Message Broker, IBM WebSphere Service
with future SOA based projects. Registry and Repository.
򐂰 Security pattern: IBM Tivoli® Directory
Server, IBM Tivoli Federated Identity
Manager, IBM Tivoli Access Manager.
򐂰 Management pattern: IBM Tivoli Composite
Application Manager for WebSphere
Application Server, IBM Tivoli Composite
Application Manager for SOA, IBM Tivoli
Monitoring.
򐂰 Governance pattern: IBM Rational Asset
Manager, IBM Tivoli Change and
Configuration Management Database, IBM
Rational Method Composer
Core business patterns

This section describes the core business patterns adopted by JKHL Bank in more detail.
Applying the Entity Analytics business pattern

This pattern is used to address the following challenges:
򐂰 Current analytical tools support only Soundex-based identity recognition, leading to
inaccuracies in identifying potentially fraudulent applicants and contributing to high false
positives that abnormally increase analysts workload.
򐂰 The bank needs more precise and comprehensive tools to identify the beneficial account
owner, and understand the ownership and control structure of the customer.
򐂰 With newer business channels such as online and mobile, fraud opportunity is much
greater leading to increased regulatory compliance needs.
򐂰 Without effective tooling for applicant screening, the bank risks losing business as a result
of negative customer experiences.
How JKHL Bank applied this pattern

򐂰 The bank integrates the functionality of this pattern into the Account Origination processes
across all lines of business. The bank uses the Entity Analytics pattern for:
– Identification and relationship resolution against OFAC, PEP, 314A and internal bad
lists.
– Online account applications, implementing additional checks using electronic
information such as MAC addresses, e-mail, and IP address.
򐂰 Alerts are included on personal attribute matches, culture-based name comparison scores
and match information with suspect individuals.
򐂰 A decision tree is used to generate a model, optimized for the business objectives, with
observations on historical data.

򐂰 Security/audit investigators are provided with a comprehensive “criminal-network” view,
relevant to the entities involved for informed decision making.
򐂰 Details of identity/relationship resolutions are maintained for each alert.
򐂰 The bank can accumulate an appreciating asset Identity Repository used for perpetual
historical review.
Implementation of this pattern is shown in Figure 9.
Identity Insight
(Perpetual, Streaming, Real-Time Analytics)
New
Each new applicant compared to
Applicants
key historical holdings instantly.
Who is who? Who knows who? Who does what?
Establish unique identity Obvious & non-obvious Events & transactions

Integrate data silos Links people & groups Complex event processing
DIGITAL Physical/Digital attributes Degrees of separation Criteria based alerting
People & organizations Role alerts Quantify identity activities
Biometric validation
Multicultural names
Payments
1D 1D
10s egre egre
to Marc
e
Marc
e
!
2 Degrees
2 Degrees
#9453 #9453
1,000s
of Marc Bob Bob
Alert!
#6111 #6111
sources #9453
CHKG: 4921011 e e
egre egre
SAVG: 5212110 1D 1D
MORT: 8585821 John John
CARD: 9653233 #2969 #2969
Identity Relationship Event
Flexible and Configurable Software Platform

Figure 9 Identity insight
IBM Banking Industry Framework component used to implement this pattern

򐂰 IBM InfoSphere Identity Insight Solutions (comprising of IBM InfoSphere Identity Insight
and IBM Anonymous Resolution).
򐂰 IBM InfoSphere Global Name Recognition
Business value of adoption

򐂰 IBM InfoSphere Identity Insight Solutions evaluates the applicant's physical representation
(name, address, phone, SSN, and so forth) as well as the applicant's digital representation
(IP Address, Cookie, and so forth) to detect and mitigate fraud.
򐂰 IBM InfoSphere Identity Insight Solutions develops and maintains a holistic cross product
and line of business understanding of the bank's customers that spans all representations.
Doing so helps mitigate cross-channel fraud.
򐂰 Consolidated information in identity repositories called Entity Dossiers greatly increased
accuracy in pinpointing bad guys.

򐂰 Reduction in false positives.
򐂰 With integrated identity and transaction information, case workers focus on decision
making and not querying multiple systems.
򐂰 Minimized manual investigations by Financial and Fraud Investigative Units.
Applying the Risk Analytics business pattern

򐂰 JKHL Bank needs all-inclusive analytical and reporting tools to supplement current tooling,
to detect early warnings of credit deterioration.
򐂰 Home-grown analytical applications to conduct predictive scoring of new customers have
technology limitations and take several months to accommodate changing requirements.
򐂰 JKHL Bank prefers to supplement their current reporting structure with proven reporting
templates that can be easily and quickly customized to meet their needs.
򐂰 Regulatory reporting requires investigative time and effort, involving manual queries from
various systems.

JKHL Bank focuses on three types of Risk Analytics:
򐂰 The bank has adopted a more robust predictive analysis engine covering KYC and fraud
scoring.
򐂰 A new dimension of data analysis is added to existing credit risk checks:
– Create a report based on performance of the bank’s existing borrowers with similar
profiles (same geography, product, and credit scores) for underwriting use.
– Add new data dimensions into the credit risk analysis based on the current customer
base with similar profile provides a way to develop the bank’s own risk rating system,
trigger alerts for amendments to the loan offer (risk-based pricing), making this an
exhaustive credit risk exposure analysis process.
– The bank also extends the Risk Analytics pattern to outside the Account Originations
process by implementing analysis of the bank’s risk exposure and reporting that serves
the Risk COE and Underwriting management.
IBM Banking Industry Framework components used to implement this pattern

򐂰 IBM Cognos BRP Analytical Application for business intelligence, dashboards and
reporting within and outside the Account Originations process.
򐂰 Recommended offerings for predictive analysis capabilities from SPSS, an IBM Company,
Norkom, Actimize, ACI, and FICO.
Applying the Risk Analytics business pattern for KYC and fraud risk
predictive analysis
The Risk Analytics pattern is applied specifically for KYC and fraud risk predictive analysis to
address the following challenges:
򐂰 JKHL Bank needs an automated and consistent solution to:
– Risk assess all new customers for KYC regulatory requirements.
– Effectively screen all applications for applicant, property appraiser, and financial fraud.

򐂰 Both screening services for KYC and fraud risk scoring:
– Need to be customer-friendly and non-intrusive
– Cannot require significant associate training
– Must route alerts to designated investigative units

򐂰 The bank integrates KYC and fraud risk scoring functionality into the Account Originations
processes across all lines of business.
򐂰 KYC and fraud risk scoring processes use data already captured as part of an application
process to determine areas of higher risk.
򐂰 KYC scores and relevant information on all applicants are automatically captured and
stored, facilitating regulatory compliance with data retention requirements.
򐂰 Alerts are automatically routed to the appropriate area (Financial Investigation Unit [FIU]
or Fraud Investigations) for investigation.
򐂰 If an alert is created, the process can continue forward but the file is flagged and cannot
be funded until all investigations are cleared, permitting faster decision making while
ensuring appropriate due diligence is conducted.
򐂰 While FIU and Fraud Investigations are distinct units, both areas use an integrated
financial crimes platform, allowing both areas to identify current and previous
investigations related to their person of interest.
򐂰 Key information associated with all investigations is automatically saved for the required
five-year period.
This pattern is applied as shown in Figure 10 on page 22.

Intelligent feedback Collaboration
Financial Crimes Steering Committee

Product
Business Intelligence
Development
Marketing
Fraud AML Corp. Security
Legal
Analysts & Investigators

Collections
Integrated Crimes Platform

AML AC
Paym
Mort
On-li ng
Depo
bank
Insid
Cred
OF
Card
gage
BSA
ents
ne
i
er
it
sit
Figure 10 Risk Analytics for KYC and fraud predictive analysis
Critical components of the KYC / fraud risk assessment solution

򐂰 Integrated with the account origination system
򐂰 Highly-flexible scoring system
Table-driven decision criteria
򐂰 Includes Investigative Case Management
– Highly-automated
– Linked to key source data
– Automated escalation
򐂰 Automatically generates key reporting
– SARs
– CTRs
– Managerial dashboards
Recommended solution offerings from ISVs

򐂰 SPSS, an IBM Company
򐂰 Norkom
򐂰 Actimize
򐂰 ACI
򐂰 FICO

Applying the Risk Analytics business pattern for credit risk analysis
The Risk Analytics pattern is applied specifically for credit risk analysis for Account
Originations and the Risk COE to address the following challenges:
򐂰 JKHL Bank uses IBM Cognos Banking Risk Performance (BRP), which includes a
complete metadata model of risk drivers, predefined reports and best practices associated
with credit risk portfolio management.
򐂰 As part of the loan origination process, BRP uses the Analytic Application Framework to
build dynamic reports for underwriting to compare the current performance of borrowers
with similar loan profiles, against new applicants.
򐂰 Risk COE and underwriting management receive monthly reports through Web browsers,
smart phones, and spreadsheets on asset quality throughout the loan management cycle,
which guides the processing regulation for future loans.
򐂰 The BRP reports are built as a widget in the underwriter’s mashup page.
򐂰 Customizable predefined BRP reports and templates provide better insight into
information, including:
– Originate loans that are in-line with tighter lending standards.
– Modify delinquent mortgage loans according to LTV ratios.
– Detect loan concentrations by product and geography.
– Provide credit risk reporting at the portfolio level.
The use of IBM Cognos Connection is shown in Figure 11 on page 24.

Figure 11 IBM Cognos Connection

򐂰 JKHL Bank was able to continue using homegrown reporting applications for certain tasks,
while supplementing them with Cognos BRP for newer requirements.
򐂰 The Cognos Analytic Application Framework, which uses a mix of a build and buy
approach allowed the bank to use over 70 highly adaptable reports out of the box as well
as configure new dimensions, measures and reports to create an end-to-end library.
Cognos BRP provides a platform to jump-start implementation of a credit risk reporting
process or add business value to existing implementations.
Applying the Business Rules Integration and Automation business

pattern
򐂰 Multiple, disparate systems are in place where business rules are hard-coded and
decentralized.
򐂰 The current system does not provide sufficient flexibility, agility and auditability.
򐂰 JKHL Bank currently runs policies in batch-mode but needs to adopt technology that will
allow real-time interactions in credit-granting, product cross-sell, and fraud detection.

򐂰 The bank is unable to enforce consistent KYC and on-boarding rules across different lines
of business and channels.
򐂰 Manual intervention is prevalent in parts of the automated Account Originations processes
for simple to critical decision making.
򐂰 Staffing levels have grown significantly to manage the case load generated by disparate,
critical systems. There are high operational costs and inconsistent decisions associated
with high staffing levels, causing customer satisfaction issues and poor application of risk
criteria.
򐂰 The bank is unable to respond to swiftly evolving fraud types.
򐂰 Business analysts and policy makers lack tools to make direct policy changes. All changes
have to go to the IT department, leading to delays in event fulfilment.

򐂰 A Business Rules Management System (BRMS) is implemented, which allows business
policies to be extracted from software code and managed directly by the bank’s business
managers.
򐂰 Business policies for all account origination processes, across multiple lines of business
(LOB), are centralized in the BRMS repository
򐂰 Key processes in which business rules are implemented:
– Risk-based pricing, decision support for KYC and fraud scoring, support for credit
qualification and customer segmentation.
– Regulatory and governance compliance, change management and logging, audit trails,
application of specific security/change protocols
– Regulatory compliance such as decision automation, auditing and tracking, adjustment
to changes.
– Fraud prevention through real-time interaction with the authorization system,
transaction routing, case/alarm generation and exception handling.
– Investigation such as case creation, prioritization, and case management.
򐂰 In addition, business rules are extended to other areas such as:
– Product assignment cross-sell, up-sell, at account opening, and throughout the
customer life cycle.
– Customer management developing a single view of the customer for life cycle product
assignment.
– New products are now brought to market in days rather than the months that were
taken previously.
򐂰 Changes made to any part of these processes going forward are managed and executed
by line of business managers and analysts and not by the IT department.
򐂰 Changes are applied with consistency across different LOBs ensuring that overall risk
management criteria are respected.

This pattern is implemented by IBM WebSphere ILOG BRMS. Using IBM WebSphere ILOG
BRMS empowers JKHL Bank to make better decisions faster, easily managing change and
complexity.

IBM WebSphere ILOG BRMS provides:
򐂰 Business rules management without significantly specialized skills
򐂰 Flexibility to change rules quickly and often
򐂰 Rule maintenance achieved up to 90% faster
򐂰 Impact (What-if and Champion-Challenger) analysis before committing policy changes
򐂰 Audit trail and transparency: readable, auditable, versionable, reportable
򐂰 Efficient and iterative development process
򐂰 Build/test independence from delivery platform
򐂰 Simplification of complex structures
򐂰 Scalability and high performance with large volumes of rules
򐂰 Hot deployment of rules
IBM WebSphere ILOG BRMS is shown in Figure 12.
BPM IBM ILOG

Application BRMS
Processing
Electronic submission parameters Transparent
Fraud Decision
Detection Report parameter Service
(e.g., exception) Rule Designer
Exception? Exception
handling
Yes
No Deploy rules
No Yes
FIU
Review
Required? Order validation rules
Fraud detection rules Rule
Computation rules Repository
Conduct
Credit Risk Route to FIU
Analysis
Figure 12 IBM WebSphere ILOG BRMS

򐂰 There is a natural progression for ongoing process automation improvements. The bank’s
goal is met in terms of limiting manual intervention to exceptions only.
򐂰 Analyzing traces and reports allows the bank to understand what, when, and how policies
and rules are breached and why.
򐂰 Authoring of rules and policies is by the business users, minimizing IT involvement.
򐂰 Editing and changes are in a business language (no coding required), saving on IT
resources and cost.
򐂰 Testing and simulation is by the business users, providing more flexibility for change.
򐂰 Managing the validation of rules in an automated process allows the embedding of the
best practices in the system.
򐂰 JKHL Bank now has control of its critical processes and is delivering superior customer
satisfaction with increased revenue and margins.

Applying the Interaction and Collaboration using Mashups business
pattern
򐂰 In the Account Originations process, suspicious applications are routed to the
Financial/Fraud Investigative Units (FIU) for manual investigation.
– The financial investigators in the FIU need to query multiple systems/sources manually,
both internal and external to the bank, to gather the information required for
investigation.
– Because the process is manual, different agents look at different sites and sources. In
particular, some external sources are easily missed.
򐂰 Underwriters spend considerable time looking through various systems for inputs into their
underwriting process. They need a way to ensure a more productive use of their time and
effort.
򐂰 There are limited IT funds and resources to create a new, homegrown, fully supported
application to meet the needs of the FIU investigators and underwriters.

򐂰 The bank invests in a flexible dashboard to perform financial and fraud investigations, by
using mashup technology. A mashup is a lightweight Web application created by
combining information or capabilities from more than one existing source to deliver new
functions and insights.
򐂰 Using this technology, JKHL Bank implements the following:
– A investigation mashup that provides internal processing results from identification and
relationship matches, predictive analysis scores, customer application information
along with a list of associated accounts, context sensitive help from wikis combined
with data from external sources such as credit reports, publicly available data, property
information, and so forth.
– Adding new data sources to pages or changes to views, to suit the needs of users can
be easily accommodated in a short span of time.
– When ready, the investigator and underwriters can submit a report from the same page
about the alert and assign a resolution.
– The alert status can be communicated to the loan processors and external government
bodies thorugh the Web, e-mail, or other messaging tools that can also be accessed
from the same mashup.
– The same base user interface can be easily customized for other users, reusing
common widgets and data sources without having to build the entire mashup from
scratch.

JKHL Bank uses IBM Mashup Center for mashup user interface creation and data mashups.
IBM Mashup Center is a complete end-to-end mashup platform, supporting line of business
assembly of simple, flexible, and dynamic Web applications with the management, security,
and governance capabilities IT requires.

IBM Mashup Center supports:
򐂰 Quick assembly and sharing of new mashups.
򐂰 Secure unlocking of enterprise information.
򐂰 Transformation, merging and mixing of enterprise information and Web information to
provide useful insights within a short span of time.
򐂰 Increase in reuse of services.
򐂰 Discovery of existing mashable assets (such as feeds, mashups, widgets).
JKHL Bank uses these components of IBM Mashup Center:

򐂰 Mashup Builder enables quick and easy creation and assembly of mashups on-the-glass.
򐂰 Data Mashup Builder enables unlocking, transformation and sharing of Web and
enterprise information.
An example of a mashup is shown in Figure 13.
Figure 13 IBM Mashup Center

򐂰 Investigators and underwriters quickly uncover new business insights with assembly of
information from multiple sources on-the-glass.
򐂰 Increased agility by supporting dynamic assembly and configuration of applications when
modifications to views are needed.
򐂰 JKHL Bank saves IT costs and resources through speed of development and through
lightweight integration, reuse, and sharing.
򐂰 The solution supports JKHL Bank’s SOA mission with reuse through discovery of
mashups, widgets, feeds, and services.
Core SOA infrastructure patterns

In addition to the core business patterns discussed above, SOA infrastructure patterns are
also required to make the solution implementation robust, provide flexibility and
enterprise-wide security, monitoring and governance. This section describes the core SOA
infrastructure patterns adopted by JKHL Bank in more detail.
Applying the simple connectivity pattern

The simple connectivity pattern describes how multiple internal clients can access services
within an organization, for example, this SOA pattern can be used to describe how remote
offices of an organization access headquarter systems using Web services standards.
Technical problem
JKHL Bank’s environment is tightly coupled and contains many point-to-point connections
between several business applications, making it inflexible to change current systems and
easily add new ones. The bank needs hundreds of project hours to make changes to their
existing monolithic, home grown, and heritage applications to meet new business
requirements. Integrating these heritage applications with front-end applications is also a
challenge. Additionally, because JKHL Bank acquired and merged with other banks over the
years, applications and data became even more disintegrated.

JKHL Bank adds an Enterprise Service Bus (ESB) into the corporate data center. The ESB
provides loose coupling, basic routing, and integration to many of the heritage applications,
such as the retail banking system in HOGAN, credit card and capital marketing systems in
IMS™, and other packaged applications.
The ESB provides support for multiple protocols and message formats between applications
at the channels and corporate data center. IBM Information FrameWork provides the initial
services design using the Financial Services-Interface Design Model (FS-IDM) to provide a
common service language for JKHL Bank.

JKHL Bank applies this pattern, as shown in Figure 14.
Enterprise
Information
Process Manager Systems
Service Registry & Service Mgmt & External

Enterprise Service Bus Repository Invocation Services Gateway
Insight 3rd Party
Banking Industry
and Analytics Master Unstructured Data
Data Data
Models
Mgmt
Figure 14 Simple connectivity pattern
IBM components used to implement this pattern

򐂰 IBM WebSphere Enterprise Service Bus
򐂰 IBM WebSphere Message Broker
򐂰 IBM WebSphere DataPower®
򐂰 IBM WebSphere Service Registry and Repository

The ESB provides a solution to serve requests in a channel agnostic fashion to support user
interface flexibility. The ESB also provides the ability to modernize, extend, and customize
existing high-value core banking applications and data without having to completely replace
these systems, which results in extensive cost savings.
Applying the SOA Security pattern

The SOA security pattern covers aspects of security management in two areas:
򐂰 Consistency of security policy and configuration across a multiple set of endpoints for
authorization, message security, and access control.
򐂰 Management of identities within SOA environments.
Technical problem
JKHL Bank needs an integrated and centralized SOA security policy management across all
endpoints for interactions with service requestors and providers. The bank needs to manage
identities efficiently, and this identify information must be available across request flows
(including access to services on z/OS®). The security of transactions is important to JKHL
Bank, and they must assess compliance to their business policies.

JKHL Bank adopts a federated security framework that is a combination of mainframe
security (such as ACF2 and RACF®), Java™ security, LDAP, firewall security, message
security, and Web-based security. Enforcement of authentication is managed by a
combination of JKHL Bank’s enterprise access server authentication module and IBM Tivoli
Directory Server.

JKHL Bank uses Tivoli Federated Identity Manager to support a security token service that
maps identities and tokens as they flow from requestors through the ESB to service
providers. Tivoli Access Manager enforces authorization policies.
Business value-of-adoption
By adopting a federated security approach, JKHL Bank can secure its environment
end-to-end, control access to its back-end systems, and comply with security policies across
all business applications.
Applying the SOA management pattern

SOA management covers aspects of monitoring and managing SOAs.
Technical problem
JKHL Bank wants to manage composite applications efficiently, which includes life cycle
management, business processes, transactions, Web services, and interactions with
partners. The bank needs to monitor transactions closely, which includes services on z/OS.
Contextual information must be available for critical points in the flow. The bank needs the
ability to specify service level agreements (SLAs) and monitor and report them.

JKHL Bank uses a variety of IBM products to implement SOA management:
򐂰 IBM Tivoli Composite Application Manager for WebSphere Application Server monitors
the portal, ESB, and business process execution.
򐂰 IBM Tivoli Composite Application Manager for SOA monitors service requests that flow
from the process engine to the core banking systems and MDM repository.
򐂰 IBM Tivoli Monitoring monitors service components against SLAs.
򐂰 IBM Tivoli Enterprise Console/Omnibus is the IT event management system that aids
problem determination.
򐂰 IBM Tivoli OMEGAMON® XE for CICS® monitors and manages CICS transactions and
resources on z/OS.
򐂰 IBM Tivoli Change and Configuration Management Database is the platform that is used
to store deep, standardized enterprise data.
Business value-of-adoption
By implementing a mechanism to perform event correlation across IT tiers, JKHL Bank
reduces time for problem determination. For example, if interaction services or business
partner services are down, less time is spent in analyzing events that the middleware emits.
Management of systems on z/OS helps to detect and isolate problems quickly when they
occur on complex CICS systems. Integrating, automating, and optimizing data, workflows,
and policies helps JKHL Bank align the ongoing management of its infrastructure with its
business.
Applying the SOA governance pattern

The SOA governance pattern includes regulating new service creation, getting more reuse of
services, enforcing standards and best practices, service change management and service
version control, and implementing SOA policy.

Technical problem
JKHL Bank has no enterprise-wide governance strategy. The execution of governance
practices are currently manual, but the bank needs proactive best practices and enforcement.
Compliance reports must be stored and retrieved for audits. Because the bank is now
embarking on the SOA path, they are struggling to identify new service candidates and
prioritize these candidates.

JKHL Bank plans, develops, and deploys an enterprise-level governance strategy that aligns
with business objectives. They institutionalize governance best practices with executive
sponsorship and support across lines-of-business. Artifacts are built based on best practices
from the IBM Information FrameWork process, IBM Information FrameWork data, and IBM
Information FrameWork service models, which are now managed as part of the overall
solution life cycle.
JKHL Bank now complies with government, banking, and regional regulations, such as ITIL®,
SOX, and Basel II. To regulate the creation of new services with future SOA projects, JKHL
Bank implements a centralized registry and repository, using a combination of Rational Asset
Manager, WebSphere Service Registry and Repository, Tivoli Change and Configuration
Management Database, and Rational Method Composer.

By adopting an enterprise-level governance strategy, JKHL Bank benefits from reduced costs
because the standards enforce usage of the same monitoring tools, technologies,
procedures, and reporting for audit compliance.
JKHL Bank has now reduced exposure to litigation and is trusted by its customers and
partners by following banking, government, and regional regulations.
Solution architecture
By applying the SOA patterns, Geoffrey Carroll (with his team of IBM consultants) and Sandy
Osbourne-Archer can define a proposed solution architecture for JKHL Bank. This is shown
in Figure 15 on page 33.

Channels Enterprise Business Banking &
Information Mgmt Credit
Branches Operations
Systems
Debt Credit Cards
Business Processes Customer
Relationship General
Channel Mgmt
Risk
Ledger
Integration Service
Service Marketing
Marketing
Processes
Processes Processes
Processes Corporate
Marketing Fraud
Banking
Business
Forms Electronic Compliance
Compliance Sales Partner Decision Retail
Call Centers Mgmt Signature Processes
Processes Processes
Processes Support Product
Services Banking
Real Relationship Loan
Campaign Mgr Management Resource
Origination
Customer Process Models
Utility 3rd Party Case
Regulatory Payments
Systems Process Manager
Products/Svcs Management
2
Presentation/Interaction Services
Enterprise Access Services 4

Multi-Channel Integration
Internet Thin
Client Service Registry & Service Mgmt & External
Enterprise Service Bus Repository Invocation Services Gateway
Data Integration/
FICO
Customer Information Services Credit
Analytics
Banking Industry
Scores
Rich
Client
Relationship Threat &
Models
Master Content Demographic
Fraud
Managers/ Insight Data Mgmt Data
Agents Mgmt Systems
3rd party
3 Credit Risk
Analytics
Party
Data
Customer Document
Account
Account Mgmt
Product
Product Systems
Business
Insight
Banking Unstructured
Mobile Data
Data
Data
Banking Marts
Warehouse
Insight &
Analytics Data
Data
1 Warehousing
Warehousing Information
Foundation
4
Security,
Governance
Management
& Monitoring
& Governance
Rapid Development & Integration
Figure 15 Solution architecture for JKHL Bank
Geoffrey Carroll describes how the SOA business and infrastructure patterns relate to this
solution architecture. The numbers shown in Figure 15 relate to the following SOA patterns:
1. The Insight and Analytics component of the solution architecture uses the following SOA
patterns:
– Entity Analytics business pattern
• Strengthens Account Origination processes by the use of strategic concepts such
as identification and relationship resolution, and fraud detection.
• With integrated identity and transaction information, case workers focus on decision
making and not querying multiple systems.
– Risk Analytics business pattern
• Provides access to a thorough and holistic view of a customer’s credit exposure, so
loans can be originated in-line with tighter lending standards.
• Improved analytics by integrating predictive analysis with identification resolution,
providing the bank with early detection of risky applicants and better control on the
risk exposure.

2. The Process Manager component of the solution architecture uses the Dynamic Business
Rules Integration and Automation business pattern
– Manages simple to complex decision making, exception processing and routing in an
automated process, allowing the embedding of leading practices in the system.
– JKHL Bank now has control of its critical processes and can deliver superior customer
satisfaction with increased revenue and profit margins.
3. The Channel Integration component of the solution architecture uses the Integration and
Collaboration SOA pattern using Mashups business pattern
– Increases agility by supporting dynamic assembly and configuration of applications.
– JKHL Bank saves IT costs and resources through speed development and through
lightweight integration, reuse, and sharing.
4. The Enterprise Service Bus and Security, Management, and Governance components of
the solution architecture use the Connectivity, Security, Management, and Governance
SOA pattern.
– Robust SOA infrastructure provides for rapid, flexible application development and
reduces costs.
– Enables reuse of existing assets and services.
– Provides security, management and governance services across the enterprise for an
optimal operational environment and success with future SOA based projects.
Summary
By adopting the business and infrastructure patterns roadmap, JKHL Bank can construct a
solution to improve top-line growth, reduce costs, reduce operational risks, and improve
customer experience.
IBM SOA Sandbox

Get hands-on experience at no cost with the IBM SOA middleware portfolio in a Cloud
environment through the IBM SOA Sandbox at the following Web page:
http://www.ibm.com/developerworks/downloads/soasandbox/
The team who wrote this IBM Redpaper

This paper was produced by a team of specialists from around the world.
Martin Keen, Consulting IT Specialist, IBM ITSO
Simon Darby, Associate Partner, IBM Global Business Services®
Rashmi Kaushik, Industry Scenarios Product Manager, SOA Advanced Technologies
Paul Leonhirth, Integrated Risk Management Solution Sales
Robert Molloy, Associate Partner, IBM Global Business Services
Jeffrey Skinner, Banking Industry Sales Representative
Robert Snider, FSS Industry Solutions Architect

Thanks to the following people for their contributions to this project:
򐂰 Francis Tonyan, IBM Identity Resolution Sales
򐂰 Jason Salcido, IBM Cognos Architect
򐂰 Richard Collard, IBM iLOG Business Lead and Fraud Expert
򐂰 Amod Bhise, Content Packs and IFW
򐂰 Klaus Roder, IBM Solutions Architect, IBM Mashup Center
򐂰 Santhosh Kumaran, IBM Banking Solutions Senior Manager
򐂰 Judith Escott, IBM Banking Industry Framework Offering Manager
򐂰 Stephanie Bartels, IBM Banking Industry Framework Marketing Manager
򐂰 Fred Winegust, Marketing Manager, Financial Services
򐂰 Michelle Trapani, Sr. Product Marketing Manager, SPSS, an IBM Company

Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs.
© Copyright International Business Machines Corporation 2009. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by
GSA ADP Schedule Contract with IBM Corp. 37
This document REDP-4591-00 was created or updated on December 22, 2009.
Send us your comments in one of the following ways: ®

򐂰 Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
򐂰 Send your comments in an email to:
redbooks@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400 U.S.A. Redpaper ™
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries, or both. These and other IBM trademarked terms are
marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US
registered or common law trademarks owned by IBM at the time this information was published. Such
trademarks may also be registered or common law trademarks in other countries. A current list of IBM
trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
CICS® InfoSphere™ Redbooks (logo) ®

Cognos® OMEGAMON® Tivoli®
DataPower® RACF® WebSphere®
Global Business Services® Rational Rose® z/OS®
IBM® Rational®
IMS™ Redpaper™
The following terms are trademarks of other companies:
ITIL is a registered trademark, and a registered community trademark of the Office of Government
Commerce, and is registered in the U.S. Patent and Trademark Office.
Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Other company, product, or service names may be trademarks or service marks of others.

Bank Risk Management Case Study

Uploaded by

Document Information

Original Description:

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

Bank Risk Management Case Study

Uploaded by

Copyright:

Available Formats

Martin Keen

Redpaper Simon Darby

Case Study: Risk Management Banking

This IBM® Redpaper™ publication is one in a series of service-oriented architecture (SOA)

© Copyright IBM Corp. 2009. All rights reserved. ibm.com/redbooks 1

Figure 1 IBM Banking Industry Framework

The IBM Banking Industry Framework provides the following benefits:

2 Case Study: Risk Management Banking Scenario

Risk management trends in the banking sector

The changing compliance landscape

Case Study: Risk Management Banking Scenario 3

The extent of US financial fraud, as determined by the US Financial Crimes Enforcement

Figure 2 US financial fraud

4 Case Study: Risk Management Banking Scenario

Taking an integrated approach to address regulatory compliance, fraud, and

JKHL Bank in the banking industry

Case Study: Risk Management Banking Scenario 5

Thomas has the following business objectives relating to risk management:

Business process modeling

6 Case Study: Risk Management Banking Scenario

Analyzing the mortgage origination process

Case Study: Risk Management Banking Scenario 7

Mortgage origination process summary

Loan application is Setup Loan involves

Bank Receives Setup Loan Text

Figure 3 Mortgage Originations process

8 Case Study: Risk Management Banking Scenario

Case Study: Risk Management Banking Scenario 9

name, address, tax ids, income, assets, etc.

This re-engineered process now includes:

Figure 4 Refined Setup Loan process

Refined process summary

10 Case Study: Risk Management Banking Scenario

Conduct Mortgage Due Diligence sub-process: regulatory compliance

Regulatory Compliance Checks and

If it's an existing customer, then

If confirmed For PEP and 314A, IF KYC Score

Figure 5 Conduct Mortgage Due Diligence: regulatory compliance checks

Case Study: Risk Management Banking Scenario 11

Benefits from the refined process

Conduct Mortgage Due Diligence sub-process: fraud and credit checks

Check electronic 50.0% Yes Fraud Investigative

Figure 6 Conduct Mortgage Due Diligence: fraud and credit checks

12 Case Study: Risk Management Banking Scenario

Benefits from the refined process

Case Study: Risk Management Banking Scenario 13

Create Loan Review Underwriter

All red flags

Route to FIU for Manage Loan

Figure 7 Refined Underwrite Loan process

Refined process summary

14 Case Study: Risk Management Banking Scenario

IBM Banking Payments Content Pack for WebSphere

JKHL Bank’s technical environment

Case Study: Risk Management Banking Scenario 15

Channels Business Silos Core Systems Detection Case Mgmt.

Branch Retail App

Wealth ATM/Debit Case Management

Call Center Capital

Figure 8 JKHL Bank's technical environment

16 Case Study: Risk Management Banking Scenario

There are two distinct types of SOA patterns:

Case Study: Risk Management Banking Scenario 17

Establish unique identity Obvious & non-obvious Events & transactions