Hide Notes 

Slide 1: Redpaper Martin Keen 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
Slide 2: 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
Slide 3: 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
Slide 4: 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 Other 800 Consumer-loan fraud False statement Identity theft Credit/debit-card fraud Mortgage fraud 600 Check fraud 400 200 Money laundering 1997 98 99 2000 01 02 03 04 05 06 07 08 0 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 4 Case Study: Risk Management Banking Scenario
Slide 5: 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
Slide 6: 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
Slide 7: 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
Slide 8: 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 submitted via online channel. Bank receives loan application and assigns a loan number to the application. The mortgage origination process is exemplified using the online channel in this workflow, however, similar steps apply for other channels such as branch, mobile and phone. Setup Loan involves verifying information submitted by borrowers and property info. Then, conduct fraud and customer risk rating checks. If borrowers pass the checks, then complete loan set up and order credit reports and other info for Underwriting review. Role: Loan Processor Bank Receives Customer Loan Application Setup Loan Text Underwrite Loan Prepare for Closing Loan Closing Loan Funding The underwriter receives the loan app from the queue. Reviews all available info on borrowers and creates loan conditions. If mismatch with supporting documentation. The underwriter also reviews borrowers credit and fraud reports and determines if further investigation is needed. If info submitted is sufficient to make a decision, then the loan is approved/denied/submitted for 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 nonfunded loans process. Role: Loan Processor Communicate with closing agent and schedule a closing date. Generate closing docs, review file for completion and send to Loan Closer for funding. Role: Document Coordinator/Loan Closer Contact closing agent, prepare wire information, obtain any pending docs to satisfy loan conditions and release funds. Send file to post funding queue for final checks and storing file in repository. ... Figure 3 Mortgage Originations process 8 Case Study: Risk Management Banking Scenario
Slide 9: 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
Slide 10: Refined Setup Loan process The refined setup Loan process is shown in Figure 4. Review and verify borrower and co-borrower's information is complete Review and verify property information is complete Order Credit Report and Appraisal Text name, address, tax ids, income, assets, etc. Conduct Mortgage Due Diligence Text Complete Loan Setup and Route to appropriate underwriting department based on business rules Text 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. 10 Case Study: Risk Management Banking Scenario
Slide 11: 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 50.0% Yes 50.0% Yes Check id match and/or relationship match with individuals on OFAC, PEP, 314A (suspected terrorist) and internal fraud lists and Generate KYC Risk Score Financial Investigative Unit (FIU) to check applicant information further and confirm match 50.0% No If match with OFAC 314A, PEP or internal bad list 50.0% No New customer? KYC Score presents a risk score based on borrowers information such as: entity type (enterprise, individual, charity org.), demographics, identity information. If it's an existing customer, then KYC scoring and other regulatory compliance checks are not needed since this is already done on a periodic basis 50.0% Yes 50.0% No If confirmed match with OFAC and internal bad list For PEP and 314A, put processing on hold until notification is received from FIU to proceed IF KYC Score presents high risk, then conduct enhanced due diligence Figure 5 Conduct Mortgage Due Diligence: regulatory compliance checks Case Study: Risk Management Banking Scenario 11
Slide 12: 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 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. Fraud Checks Fraud Checks via predictive analysis Check electronic information from application submission (such as MAC address, e-mail, ip address) and property information (refi frequency, pmt history, appraisal info) 50.0% Yes 50.0% Yes Deny Application Credit Checks Fraud Investigative unit Review 50.0% No Confirmed Fraud? Generate Fraud Scores for both borrower and co-borrower 50.0% No Is the electronic information or property info suspect? Conduct Credit Exposure Analysis to guage impact of borrowers' new loan on the bank, based on historical information Text Electronic info check holds good only for online e-submissions. This step does not apply if the customer is applying in a bank branch. The Credit Checks process has been enhanced to include a new dimension of data analysis – New analytical reports and intelligence will be generated for underwriting to understand the performance of existing borrowers with similar profile (credit score range, loan product, geography) as new applicant and come up with a risk rating system. This process can trigger alerts if the risk rating is not 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 12 Case Study: Risk Management Banking Scenario
Slide 13: 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 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 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
Slide 14: 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. 50.0% Yes Create Loan conditions Review Underwriter 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 property liens, tax information, appraisal, etc. Determine loan pricing and validate loan 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 further investigation Manage Loan 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. 14 Case Study: Risk Management Banking Scenario
Slide 15: 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 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. Case Study: Risk Management Banking Scenario 15
Slide 16: Geoffrey illustrates JKHL Bank’s technical environment, as shown in Figure 8. Channels Business Silos Core Systems Detection DS OD DS Case Mgmt. DS OD DS Branch Retail App Deposit DS Case Management DS OD DDA ATM Wealth Management App Merchants CF Mobile App OD DS DS ATM/Debit DS OD DS Case Management DS OD DS AML DS OD DS Case Management DS OD DS Commercial Online Credit Card Credit Card Case Management Identity CM Call Center Capital Markets App Insider CM eCommerce CM Relationship Manager Lending Systems 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). 16 Case Study: Risk Management Banking Scenario
Slide 17: 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 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. 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. 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. 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. Business patterns and IBM Banking Industry Framework components Pattern to apply: Entity Analytics pattern Products: IBM InfoSphere™ Identity Insight Solutions Pattern to apply: Risk Analytics pattern Products: 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 Pattern to apply: Business Rules Integration and Automation pattern Products: IBM WebSphere Dynamic Business Process Edition IBM WebSphere ILOG Business Rules Management System IBM Banking Content Pack for WebSphere Pattern to apply: Interaction and Collaboration using Mashups pattern Products: IBM Mashup Center (comprising of Mashup Builder and Data Mashup Builder). Case Study: Risk Management Banking Scenario 17
Slide 18: 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 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 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. 18 Case Study: Risk Management Banking Scenario
Slide 19: 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 Applicants Each new applicant compared to key historical holdings instantly. Who is who? Establish unique identity Integrate data silos Physical/Digital attributes People & organizations Biometric validation Multicultural names Who knows who? Obvious & non-obvious Links people & groups Degrees of separation Role alerts Who does what? Events & transactions Complex event processing Criteria based alerting Quantify identity activities DIGITAL Payments 10s to 1,000s of sources 2 Degrees 2 Degrees Marc #9453 1D egre e Marc #9453 1D egre e ! Alert! Marc #9453 CHKG: 4921011 SAVG: 5212110 MORT: 8585821 CARD: 9653233 Bob #6111 Bob #6111 John #2969 e egre 1D John #2969 e egre 1D 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. Case Study: Risk Management Banking Scenario 19
Slide 20: 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 This 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 pattern 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. 20 Case Study: Risk Management Banking Scenario
Slide 21: 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
Slide 22: Intelligent feedback Collaboration Financial Crimes Steering Committee Business Intelligence Product Development Fraud AML Corp. Security Marketing Legal Analysts & Investigators Collections Integrated Crimes Platform 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 BSA AML AC OF Paym gage Mort ne On-li ng i bank sit Depo er Insid it Cred Card ents 22 Case Study: Risk Management Banking Scenario
Slide 23: 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. Case Study: Risk Management Banking Scenario 23
Slide 24: 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 pattern This 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
Slide 25: 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 pattern 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. Case Study: Risk Management Banking Scenario 25
Slide 26: 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 Application Processing Electronic submission parameters IBM ILOG BRMS Transparent Decision Service Rule Designer Fraud Detection Exception? No Yes Report parameter (e.g., exception) Exception handling Deploy rules No FIU Review Required? Yes Order validation rules Fraud detection rules Computation rules Route to FIU Conduct Credit Risk Analysis Rule Repository 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. 26 Case Study: Risk Management Banking Scenario
Slide 27: Applying the Interaction and Collaboration using Mashups business pattern This 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 pattern 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. Case Study: Risk Management Banking Scenario 27
Slide 28: 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
Slide 29: 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 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. How JKHL Bank applied this pattern 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. Case Study: Risk Management Banking Scenario 29
Slide 30: JKHL Bank applies this pattern, as shown in Figure 14. Process Manager Enterprise Information Systems Enterprise Service Bus Service Registry & Repository Service Mgmt & Invocation External Services Gateway Master Data Mgmt Banking Industry Models Insight and Analytics Unstructured Data 3rd Party Data 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 adoption 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. How JKHL Bank applied this pattern 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. 30 Case Study: Risk Management Banking Scenario
Slide 31: 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. How JKHL Bank applied this pattern 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. Case Study: Risk Management Banking Scenario 31
Slide 32: 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. How JKHL Bank applied this pattern 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. Business value of adoption 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. 32 Case Study: Risk Management Banking Scenario
Slide 33: Channels Branches Business Processes Service Service Processes Processes Electronic Signature Compliance Compliance Processes Processes Marketing Marketing Processes Processes Sales Processes Processes Enterprise Information Systems Channel Integration Forms Mgmt Business Mgmt Debt Banking & Credit Operations Credit Cards General Ledger Corporate Banking Retail Banking Loan Origination Payments Customer Relationship Mgmt Marketing Risk Fraud Product Resource Regulatory Call Centers Customer Presentation/Interaction Services Multi-Channel Integration Business Partner Services Real Campaign Mgr Decision Support Relationship Management Case Management Utility Systems Enterprise Access Services Process Models Internet Thin Client 4 2 Process Manager 3rd Party Products/Svcs Enterprise Service Bus Service Registry & Repository Service Mgmt & Invocation External Services Gateway Relationship Managers/ Agents Rich Client Threat & Fraud Insight Credit Risk Analytics Business Insight Banking Industry Models Customer Analytics Data Integration/ Information Services FICO Credit Scores Content Mgmt Systems Demographic Data Master Data Mgmt Party Customer Account Account Product Product Banking Data Warehouse Data Marts 3 Document Mgmt Systems 3rd party Data Mobile Banking Unstructured Data 1 Insight & Analytics Data Data Warehousing Warehousing Information Foundation 4 Security, Management & Governance Governance & Monitoring 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. 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. – Risk Analytics business pattern • • Case Study: Risk Management Banking Scenario 33
Slide 34: 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
Slide 35: 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
Slide 36: 36 Case Study: Risk Management Banking Scenario
Slide 37: 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
Slide 38: 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® 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