Bank Risk Management Case Study

38
© Copyright IBM Corp. 2009. All rights reserved. ibm.com/redbooks 1 Redpaper 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. Martin Keen Simon Darby Rashmi Kaushik Paul Leonhirth Robert Molloy Jeffrey Skinner Robert Snider

Transcript of Bank Risk Management Case Study

Page 1: Bank Risk Management Case Study

Redpaper

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.

Martin KeenSimon Darby

Rashmi KaushikPaul LeonhirthRobert Molloy

Jeffrey SkinnerRobert Snider

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

Page 2: Bank Risk Management Case Study

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

Page 3: Bank Risk Management Case Study

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

Page 4: Bank Risk Management Case Study

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.

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

1997 98 99 2000 01 02 03 04 05 06 07 080

200

400

600

800

Money laundering

Check fraud

Mortgage fraud

OtherConsumer-loan fraudFalse statementIdentity theft

Credit/debit-card fraud

Number of suspicious-activity reports filed, '000

US financial fraud

Source: US Financial Crimes Enforcement Network

4 Case Study: Risk Management Banking Scenario

Page 5: Bank Risk Management Case Study

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

Case Study: Risk Management Banking Scenario 5

Page 6: Bank Risk Management Case Study

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.

6 Case Study: Risk Management Banking Scenario

Page 7: Bank Risk Management Case Study

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 identifying potentially fraudulent applicants.

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

Case Study: Risk Management Banking Scenario 7

Page 8: Bank Risk Management Case Study

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 summaryThe high level view of the mortgage origination process is shown in Figure 3.

Figure 3 Mortgage Originations process

Loan application issubmitted via onlinechannel. Bank receivesloan application andassigns a loan number tothe application. Themortgage originationprocess is exemplifiedusing the online channelin this workflow,however, similar stepsapply for other channelssuch as branch, mobileand phone.

Setup Loan involvesverifying informationsubmitted by borrowersand property info.Then, conduct fraudand customer risk ratingchecks. If borrowerspass the checks, thencomplete loan set upand order credit reportsand other info forUnderwriting review.Role: Loan Processor

Bank ReceivesCustomer Loan

Application

Setup Loan

UnderwriteLoan

Prepare forClosing Loan

ClosingLoan

Funding

Text

The underwriter receives theloan app from the queue.Reviews all available info onborrowers and creates loanconditions. If mismatch withsupporting documentation.The underwriter also reviewsborrowers credit and fraudreports and determines iffurther investigation isneeded. If info submitted issufficient to make a decision,then the loan isapproved/denied/submittedfor counter offer.Role: Underwriter

Loan conditions are cleared or loan is amended as needed. If borrower accepts loan offer, app is routed for drawing up docs. If loan is not accepted or approved on amended terms, loan is denied and routed to non-funded loans process.Role: Loan Processor

Communicate with closingagent and schedule aclosing date. Generateclosing docs, review file forcompletion and send to Loan Closer for funding.Role: Document Coordinator/Loan Closer

Contact closing agent,prepare wire information,obtain any pending docs tosatisfy loan conditions andrelease funds. Send file topost funding queue for finalchecks and storing file inrepository. ...

8 Case Study: Risk Management Banking Scenario

Page 9: Bank Risk Management Case Study

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.

Case Study: Risk Management Banking Scenario 9

Page 10: Bank Risk Management Case Study

Refined Setup Loan processThe refined setup Loan process is shown in Figure 4.

Figure 4 Refined Setup Loan process

Refined process summaryGeoffrey 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.

Review andverify borrower

and co-borrower'sinformation is

complete

Text

Review andverify

propertyinformationis complete

Order CreditReport andAppraisal

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

Conduct MortgageDue Diligence

Complete LoanSetup and Routeto appropriate underwriting

department basedon business rules

Text

Text

This re-engineered process now includes:1. Regulatory Compliance Checks such as KYC scoring, id checks with govt. andinternal lists.2. Fraud Checks including fraud scoring, electronic information checks, etc.3. Credit Checks using credit reports, composite scores and credit risk exposureanalysis.Key Techniques used to support the checks above are identity resolution,relationship resolution, predictive analysis and historical data analysis. Thisprocess can be reused in different account opening workflows ...

10 Case Study: Risk Management Banking Scenario

Page 11: Bank Risk Management Case Study

Benefits from the refined processGeoffrey 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.

Figure 5 Conduct Mortgage Due Diligence: regulatory compliance checks

Check id match and/orrelationship matchwith individuals onOFAC, PEP, 314A

(suspected terrorist)and internal fraudlists and GenerateKYC Risk Score

Regulatory Compliance Checks andpredictive analysis via KYC Score

50.0% Yes

50.0% No

Financial InvestigativeUnit (FIU) to check

applicant informationfurther and confirm

match

If match withOFAC 314A, PEP

or internalbad list

50.0% Yes

50.0% No

Newcustomer?

If it's an existing customer, thenKYC scoring and other regulatory compliance checks are not needed since this is already done on a periodic basis

KYC Score presents a risk score basedon borrowers information such as:entity type (enterprise, individual,charity org.), demographics, identityinformation.

50.0% Yes

50.0% No

If confirmedmatch with OFAC

and internalbad list

For PEP and 314A,put processing on

hold untilnotification is

received from FIU toproceed

IF KYC Scorepresents high

risk, then conductenhanced due

diligence

Case Study: Risk Management Banking Scenario 11

Page 12: Bank Risk Management Case Study

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.

Benefits from the refined process� 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 addressedThis 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 checksThe part of the Conduct Mortgage Due Diligence sub-process that addresses fraud and credit checks is shown in Figure 6.

Figure 6 Conduct Mortgage Due Diligence: fraud and credit checks

Check electronicinformation from

application submission(such as MAC address,e-mail, ip address) and

property information(refi frequency, pmt

history, appraisal info)

The Credit Checks process has been enhanced to include a newdimension of data analysis – New analytical reports and intelligencewill be generated for underwriting to understand the performance ofexisting borrowers with similar profile (credit score range, loanproduct, geography) as new applicant and come up with a risk rating system. This process can trigger alerts if the risk rating is notwithin threshold limits and lead to an amendment of loan offer, sothe account is originated to fit tighter lending guidelines.

50.0% Yes

Generate FraudScores for bothborrower andco-borrower

Fraud Investigativeunit Review Conduct Credit

Exposure Analysisto guage impact of

borrowers' newloan on the bank,

based on historicalinformation

DenyApplication

Electronic info check holds goodonly for online e-submissions.This step does not apply if thecustomer is applying in a bankbranch.

Fraud Checks viapredictive analysis

Fraud Checks

Credit Checks

50.0% No

50.0% Yes

50.0% No

Is the electronicinformation orproperty info

suspect?

ConfirmedFraud?

Text

12 Case Study: Risk Management Banking Scenario

Page 13: Bank Risk Management Case Study

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.

Benefits from the refined process� 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 addressedThis 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 identifying potentially fraudulent applicants.

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

Case Study: Risk Management Banking Scenario 13

Page 14: Bank Risk Management Case Study

Refined Underwrite Loan processThe 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.

Figure 7 Refined Underwrite Loan process

Refined process summaryThe 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.

Review UnderwriterDashboard containing

borrower's fraud report,risk ratings and creditexposure impact andproperty information

Create Loanconditions

50.0% No

Is there adiscrepancy

based onapplicationinformation

and supportingdocs?

50.0% Yes

Route to FIU forfurther investigation

Determine loanpricing and

validate loanproduct

Continueprocessing by

validatingproperty liens,tax information,appraisal, etc.

Manage LoanCondition

All red flagscleared and

confirmed thatproperty is not aflip or involves

fraudulenttransaction?

50.0% No

50.0% Yes

14 Case Study: Risk Management Banking Scenario

Page 15: Bank Risk Management Case Study

Benefits from the refined 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 WebSphereGeoffrey 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.

Case Study: Risk Management Banking Scenario 15

Page 16: Bank Risk Management Case Study

Geoffrey illustrates JKHL Bank’s technical environment, as shown in Figure 8.

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 Systems Case Mgmt.DetectionChannels

Mobile

Branch

Call Center

RelationshipManager

Online

Merchants

Business Silos

Retail

ATM

WealthManagement

Commercial

CapitalMarkets

DDA

CF

Credit Card

Lending Systems

App

App

App

DS

DS

DS

CM

CM

CM

CM

Case Management

OD

Case Management

Case Management

Case Management

OD

DS

DS

DS

DS

DS

DS

DS

DS

OD

ODDS

ATM/Debit

Credit Card

Insider

eCommerce

ACH/Wire

Identity

OD

DS

DS

AML

OD

Deposit

OD

DS

OD

DS

App

16 Case Study: Risk Management Banking Scenario

Page 17: Bank Risk Management Case Study

Core business and SOA infrastructure patternsGeoffrey 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:� Need identity analysis to detect non-obvious borrower

information based on name, address, email address, electronic 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.

Pattern to apply: Entity Analytics patternProducts:� IBM InfoSphere™ Identity Insight Solutions

Predictive analysis for KYC and fraud scores to limit fraud and compliance risk exposure.Need improved analytics for credit risk exposure in account origination:� Need to build a more in-depth credit risk analysis within Account

Originations using new data dimensions, reports and intelligence from current performance of existing borrowers with similar profiles and product needs. This will provide better insight during the underwriting process.

� Need for supplemental reports and dashboards for Risk COE to conduct a broader range of the bank’s credit risk analysis.

Pattern to apply: Risk Analytics patternProducts:� IBM Cognos® Banking Risk Performance –

for credit risk exposure analysis, reporting and dashboards.

� Products from SPSS, an IBM Company, Norkom, Actimize, ACI, and FICO for predictive analysis capabilities for compliance and fraud

Need for automation of business policies in Account Originations:Need to integrate business rules into the current Account Originations process to reduce manual processing of exceptions, increase efficiency in the decision making process, and provide more control to business analysts on policy changes, simulation, and testing.

Pattern to apply: Business Rules Integration and Automation patternProducts:� IBM WebSphere Dynamic Business Process

Edition� IBM WebSphere ILOG Business Rules

Management System� IBM Banking Content Pack for WebSphere

Need for aggregation of information on-the-glass for FIU and underwriting:Need for a flexible dashboard that aggregates information from internal sources (identification and relationship matches, predictive analysis scores, and customer application information) and external sources (credit reports, public information, and appraisals) to make fraud/financial investigation and underwriting more efficient.

Pattern to apply: Interaction and Collaboration using Mashups patternProducts:� IBM Mashup Center (comprising of Mashup

Builder and Data Mashup Builder).

Case Study: Risk Management Banking Scenario 17

Page 18: Bank Risk Management Case Study

Table 2 SOA infrastructure patterns used by JKHL Bank

Core business patterns

This section describes the core business patterns adopted by JKHL Bank in more detail.

Applying the Entity Analytics business patternThis 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.

Business need SOA infrastructure patterns and IBM components

� Need for a robust SOA infrastructure for rapid, flexible application development and to reduce costs.

� Need for reuse of existing assets and services.

� Need to secure, manage and govern services across the enterprise for an optimal operational environment and success with future SOA based projects.

Patterns to apply:� Rapid Development and Integration

(Service Creation) pattern: IBM Rational® Rose® Data Modeler, Rational Software Architect.

� Connectivity pattern: IBM WebSphere Message Broker, IBM WebSphere Service 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

18 Case Study: Risk Management Banking Scenario

Page 19: Bank Risk Management Case Study

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

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.

Identity Insight(Perpetual, Streaming, Real-Time Analytics)

Establish unique identityIntegrate data silosPhysical/Digital attributesPeople & organizationsBiometric validationMulticultural names

Who is who?

Obvious & non-obviousLinks people & groupsDegrees of separationRole alerts

Who knows who?

Events & transactionsComplex event processingCriteria based alertingQuantify identity activities

Who does what?

NewApplicants

10sto

1,000sof

sources

Flexible and Configurable Software Platform

Each new applicant compared to key historical holdings instantly.

!Alert!Marc

#9453CHKG: 4921011SAVG: 5212110MORT: 8585821CARD: 9653233

Payments

Identity Relationship Event

Marc#9453

Bob#6111

John#2969

1 Degree

1 Degree

2 D

egre

es

Marc#9453

Bob#6111

John#2969

1 Degree

1 Degree

2 D

egre

es

DIGITAL

Case Study: Risk Management Banking Scenario 19

Page 20: Bank Risk Management Case Study

� 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 patternThis pattern is used to address the following challenges:

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

How JKHL Bank applied this patternJKHL 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 analysisThe 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.

20 Case Study: Risk Management Banking Scenario

Page 21: Bank Risk Management Case Study

� 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

How JKHL Bank applied this pattern� 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.

Case Study: Risk Management Banking Scenario 21

Page 22: Bank Risk Management Case Study

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

ProductDevelopment

Marketing

Legal

Collections

Collaboration Intelligent feedback

Financial Crimes Steering Committee

Fraud AML Corp. Security

Analysts & Investigators

Integrated Crimes Platform

Bus

ines

s In

telli

genc

e

On-line

banking

CreditC

ard

Mortgage

Payments

Deposit

Insider

AML BSA

OFAC

22 Case Study: Risk Management Banking Scenario

Page 23: Bank Risk Management Case Study

Applying the Risk Analytics business pattern for credit risk analysisThe 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.

Case Study: Risk Management Banking Scenario 23

Page 24: Bank Risk Management Case Study

Figure 11 IBM Cognos Connection

Business value of adoption� 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 patternThis pattern is used to address the following challenges:

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

24 Case Study: Risk Management Banking Scenario

Page 25: Bank Risk Management Case Study

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

How JKHL Bank applied this pattern� 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.

IBM Banking Industry Framework components used to implement this patternThis 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.

Case Study: Risk Management Banking Scenario 25

Page 26: Bank Risk Management Case Study

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.

Figure 12 IBM WebSphere ILOG BRMS

Business value of adoption� 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.

Rule Designer

BPMBRMS

IBM ILOG

Order validation rulesFraud detection rules

Computation rules

Deploy rules

FIUReviewRequired?

No

Electronic submission parameters

NoYes

Exceptionhandling

Exception?

RuleRepository

TransparentDecisionService

ApplicationProcessing

FraudDetection

ConductCredit Risk

AnalysisRoute to FIU

Yes

Report parameter(e.g., exception)

26 Case Study: Risk Management Banking Scenario

Page 27: Bank Risk Management Case Study

Applying the Interaction and Collaboration using Mashups business patternThis pattern is used to address the following challenges:

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

How JKHL Bank applied this pattern� 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.

IBM Banking Industry Framework components used to implement this patternJKHL 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.

Case Study: Risk Management Banking Scenario 27

Page 28: Bank Risk Management Case Study

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

28 Case Study: Risk Management Banking Scenario

Page 29: Bank Risk Management Case Study

Business value of adoption� 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 patternThe 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 problemJKHL 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.

How JKHL Bank applied this patternJKHL 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.

Case Study: Risk Management Banking Scenario 29

Page 30: Bank Risk Management Case Study

JKHL Bank applies this pattern, as shown in Figure 14.

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

Business value of adoptionThe 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 patternThe 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 problemJKHL 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.

How JKHL Bank applied this patternJKHL 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.

Enterprise Service Bus Service Registry &Repository

ExternalServices Gateway

Service Mgmt &Invocation

EnterpriseInformation

SystemsProcess Manager

Insightand Analytics Master

DataMgmt

Ban

king

Indu

stry

Mod

els

UnstructuredData

3rd PartyData

30 Case Study: Risk Management Banking Scenario

Page 31: Bank Risk Management Case Study

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-adoptionBy 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 patternSOA management covers aspects of monitoring and managing SOAs.

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

How JKHL Bank applied this patternJKHL 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-adoptionBy 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 patternThe 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.

Case Study: Risk Management Banking Scenario 31

Page 32: Bank Risk Management Case Study

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

How JKHL Bank applied this patternJKHL 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.

Business value of adoptionBy 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.

32 Case Study: Risk Management Banking Scenario

Page 33: Bank Risk Management Case Study

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.

Insight &Analytics

CustomerAnalytics

Enterprise Service Bus

SalesProcesses

MarketingProcesses

ServiceProcesses

ComplianceProcesses

Governance & Monitoring

3rd partyData

Data Integration/Information Services

InformationFoundation

UnstructuredData

Mul

ti-C

hann

el In

tegr

atio

n

Customer Account Product

Rapid Development & Integration

ChannelIntegration

UtilitySystems

Service Registry &Repository

ExternalServices Gateway

Service Mgmt &Invocation

SalesProcesses

MarketingProcesses

ServiceProcesses

ComplianceProcesses

Business Processes

Security, Management & Governance

FICOCreditScores

DemographicData

Threat &FraudInsight

Credit RiskAnalytics

BusinessInsight

CustomerRelationship

Mgmt

Banking & Credit

Operations

BusinessMgmt

BusinessPartner

ServicesReal

Campaign Mgr

3rd PartyProducts/Svcs

RelationshipManagement

DecisionSupport

Marketing

CaseManagement

LoanOrigination

CorporateBanking

RetailBanking

GeneralLedger

Credit Cards

Payments

Resource

Fraud

Product

Risk

Debt

Regulatory

Enterprise Information Systems

Rapid Development & Integration

Data Warehousing

Pres

enta

tion/

Inte

ract

ion

Serv

ices

Thin Client

Rich Client

Channels

Customer

PartyAccountProduct

DocumentMgmt

Systems

ContentMgmt

Systems

MasterDataMgmt

BankingData

WarehouseDataMarts

DataWarehousing

Ban

king

Indu

stry

Mod

els

FormsMgmt

ElectronicSignature

Ente

rpris

e A

cces

s Se

rvic

es

Process Manager

Process Models

Mobile Banking

Branches

Call Centers

Internet

RelationshipManagers/

Agents

24

3

1

4

Case Study: Risk Management Banking Scenario 33

Page 34: Bank Risk Management Case Study

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

34 Case Study: Risk Management Banking Scenario

Page 35: Bank Risk Management Case Study

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

Case Study: Risk Management Banking Scenario 35

Page 36: Bank Risk Management Case Study

36 Case Study: Risk Management Banking Scenario

Page 37: Bank Risk Management Case Study

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

Page 38: Bank Risk Management Case Study

®

Redpaper™

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:

[email protected]� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. HYTD Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400 U.S.A.

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®Cognos®DataPower®Global Business Services®IBM®IMS™

InfoSphere™OMEGAMON®RACF®Rational Rose®Rational®Redpaper™

Redbooks (logo) ®Tivoli®WebSphere®z/OS®

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.

38 Case Study: Risk Management Banking Scenario