After reading so much press lately about how banking is becoming increasingly commoditized, it's great to see a story like this over at Finextra:  "Wachovia releases online retail imaging tool."  By combining image-capture with on online exception handling tool Wachovia has reduced exception-related payment delays by as much as 75%.

Very recently, I read a story about how lockbox processing, in particular, was a commodity service that banks would be wise to outsource.  Kudos to Wachovia for proving that innovation is alive and well.  I guess the question now is, how long will it take for everyone else to copy this capability?

I spent most of week-before last in Mexico City, speaking at the CL@B conference.   At one of the side events, a reception hosted by Getronics, one of our major partners, I had the chance to speak with James Gardner, who asked me if I intended to speak about anything "interesting or controversial."  Considering that this was my first speaking engagement since taking my new role on the world-wide team, I said that I hoped for an interesting talk, but controversial certainly wasn't on the agenda. 

"I see," he said.  "I opened my talk by telling them they'd all be out of business in 10 years."  ZOINKS!

Combine this with American Banker's 3 part series on the "end-game" for U.S. Banking, and the overall industry mood seems somewhat fatalistic, indeed.  What are the trends driving these radical predictions for the future of the industry, and what is technology's role in aiding (or resisting) them?

• Disintermediation, the quintessential b-school dotcom buzzword, is alive and well.  Gardner's forecast of doom rests primarily on several classic disintermediation plays.  First, peer-to-peer lending schemes like Prosper and Zopa, which seek to match lenders with borrowers directly, while still allowing the lender to manage risk thru diversification.  Second, increased competition in core banking activities from unlikely sources, to wit, PayPal.  Over $8 billion US worth of payments were processed thru PayPal in Q1 2006, and the service boasts over 100 million user accounts.  Is this a possible threat to a bank's payment processing business?  Absolutely.
  
  Considering that the core function of a bank is to act as an intermediary between borrowers and lenders, the emergence of viable disintermediaries is a source of concern.  I think it remains to be seen whether these new disintermediaries are merely a threat or a clear and present danger, as these new institutions' ability to manage risk over the long term is still unknown.  Nonetheless, complacency would not be a good approach for the incumbents.
  
• Commoditization.  Increasingly, innovations pioneered by one financial institution are quickly copied by all competitors.  Commoditization increases the threat of substitutes and eliminates the "imperfect imitability" of innovation-based inputs.  In the short run, the largest banks will benefit from this phenomena, as the truly scarce input becomes the scale at which they can make investments.  As Bank of America CEO Ken Lewis pointed out in a recent American Banker interview, "Look at what size allows you to do when you want to make an investment. We made a $675 million investment last year [in the global investment bank] and never asked for forbearance from analysts."  In addition to sheer scale, brand power leans in favor of the largest players.
  
• Open Architecture.  Some large universal banks, offering a range of products and services, have come to the conclusion that they do not wish to organically provide all of these financial products.  Everything from major products like retirement accounts all the way down to gift cards at the teller counter can be offered thru "open architecture," another catch-phrase that essentially means acting as a distribution channel for other firms' financial products.

Taken together, commoditization and open architecture are causing the industry to re-think the horizontal and vertical integration decisions of the past several years, resulting in a slew of both M&A and divestiture activity.  Why not outsource a commodity line-of-business?  Why broaden our investment product portfolios thru open architecture?  What product or service do we provide better than anyone else?  Questions like these are sure to be debated as banks try to find the optimal mix of organic growth and open architecture offerings to maximize profits moving forward.

So where does technology fit?  In short, I think it all comes back to two things:  SOA and composite applications.

• SOA is an absolute good.  The ability to integrate systems based upon open XML standards will allow big banks to tailor their value-chain more optimally.  One of the classic arguments in favor of vertical integration is the elimination of transaction costs, because it is simply too costly to contract and coordinate activities across firm boundaries.  However, service-oriented architectures hold the promise of greatly reducing the friction of crossing firm boundaries, especially in a areas like financial services where the transaction involves pure information (as opposed to physical transfer of "real world" boxes, steel coils, or hog bellies).
  
  Smaller institutions likewise benefit from SOA, as it enables them to build diverse product portfolios thru the use of open architecture.  In this regard, community banks can look small, providing the local expertise and personal touch of a small-town bank, but act big by providing an array of products and services that rivals their massive competitors.
  
• Composite applications provide a user-friendly, integrated front-end that looks like one application but is actually talking to many back-end systems.  A composite app is "composed" of many autonomous pieces. Here, "autonomous" means "not sharing programmatic type information", but if that's too geeky for you, consider the benefits:  multiple application teams concurrently developing sub-pieces of the composite application, which can then be brought together in different combinations to meet different business needs.  For example, a teller may need to see a common customer module, a cash deposit module, and a bill-payment module.  A call center agent, however, may need the same customer module along with an escalation management module and sales module.  Because the composed pieces are loosely-coupled from one another and communicate across defined boundaries using XML messages, composite applications are like an SOA-based desktop application.
  
  The type of flexibility provided by composite applications is valuable to organizations of all sizes.  For large banks, the ability to allow geographically and organizationally dispersed development teams to create and deploy (and fix) their applications independently, without affecting other UI components is a huge benefit.  Citigroup's Citivision application (case study here) is a great example of this benefit in action. 
  
  For small banks that build their value chains thru open architecture, the desktop can become an unusable mess of internal and business partner systems--unless you build a composite application that smoothly integrates all of these applications into a single UI.

I'd like to pass along these announcements (regarding case studies, events, and tools), courtesy of Mike Wons, another member of our team.

Financial Services Firm Supports Growth Through Microsoft Infrastructure Optimization

• HSBC acquired a large local bank in Mexico with more than 1,400 branch locations and wanted to take control of its decentralized IT environment. Manual deployment of software applications and security updates could take months, and the company lacked tools to monitor its IT resources effectively. To improve system management, HSBC Mexico implemented a centralized solution based on the Windows Server 2003 operating system and the Active Directory service, Systems Management Server 2003, and Operations Manager 2005. Now the company can automatically install updates, get new financial service software to market quickly, and cut IT travel costs. It can also monitor systems in real time and plan for change and business growth. HSBC Mexico estimates that effective management of IT resources will help it support up to 30 percent growth with its existing infrastructure.  Full case study and one page PPT slide on the effort is posted at:  http://members.microsoft.com/CustomerEvidence/Search/EvidenceDetails.aspx?EvidenceID=14540&LanguageID=1

Unwrapped for Financial Services III - September 6-12, 2006

• Now in its third year, the Unwrapped for Financial Services webcast series is back! Sessions will be both technical and strategic in nature, covering the newest Microsoft solutions for Capital Markets, Retail Banks, Corporate and Investment Banking and Insurance firms. All the sessions will be presented live. Join us for this new webcast series starting September 6, 2006, where we will highlight common concerns, case studies and best practices within financial services. View available sessions and registration information at the following location: http://www.financialdevelopers.com/registration.aspx 

Regulatory Compliance Planning Guide

• The Regulatory Compliance Planning Guide is intended to help IT professionals and others understand steps that can be taken to help address regulatory mandates. The Planning Guide: Shows IT professionals how they can use an IT controls framework to help address IT compliance requirements; Includes a mapping of several significant regulations and standards, including the Sarbanes-Oxley Act (SOX), Gramm-Leach-Bliley Act (GLBA), and Health Insurance Portability and Accountability Act (HIPAA) to a sample control framework and Directs customers to Microsoft resources that can help them address their compliance requirements.  The 71 page Regulatory Compliance Planning Guide is available for download at the following location: http://www.microsoft.com/technet/security/topics/complianceandpolicies/compliance/rcguide/default.mspx?mfr=true

MSDN Architecture Center Channel Launched for Financial Services

• New MSDN Solution Architecture Center has been launched to provide customers and partners with guidance around architecture challenges in Financial Services.  This portion of MSDN is targeted toward the architects focused on solutions and compliments the Financial Developers site (www.financialdevelopers.com) to provide several great resources to help support our Industry story in Financial Services.  The site is accessible at: http://msdn.microsoft.com/architecture/industry/finservs/

Tech-Ready (Microsoft's internal technical conference) opened today, and I spent most of the day digging into our workflow stack, in addition to getting some hands-on experience with System Center Data Protection Manager (DPM) 2006.  I'll discuss DPM in another post, though.  For now, I'd like to take a look at what's coming in our workflow stack and how it applies to the banking industry.

Just to get some context on the state of workflow within the industry today, consider these recent articles.

• "Automated workflow is the holy grail of back office efficiency for financial services providers" according to research conducted by EasyLink Services and released to Finextra.  Based upon interviews with 50 CIOs, 63% identified workflow as the greatest opportunity, while 32% cited improved document management capabilities as the primary concern.  In the context of how Microsoft envisions workflow, I think these two priorities have some interesting linkage that I'll discuss shortly.
• Bill McFarland, in an article on GonzoBanker, observes that "the procedures and processes involved in the creation and maintenance of borrower, note and collateral files" are still "stuck in the ’50s" in terms of automation.  He then goes on to describe a host of well-automated deposit-side business process workflows, which stand in stark contrast to the largely manual, paper-based processes associated with commercial lending.

The type of automation that Bill describes when he asks the reader to imagine a better workflow process consists of two basic categories of activities:

• Document-centric activities, like gathering appraisals and other supporting documents into the loan file and making this material electronically available to all the parties at the bank who need it (such as credit analysts).
• System-centric activities, like automatic updates between the lending system, the core system, and other information systems within the bank to ensure that all enterprise systems reflect current information about the borrower.

Revisiting the CIO survey, I think the people who cited workflow and those who cited document management share a common set of concerns in many cases.  Perhaps the document management crowd simply hoped for improvements in areas like version control and records management, but even these types of document-centric features are valuable only within the context of a business process--aka, a workflow--that requires this type of functionality.  Other document management features, like routing and approval of forms, are really just a specialized case of workflow.

We call workflows that combine both document-centric and system-centric activities within a unified framework "People Ready Processes" (a not-so-surprising tag line, if you watch enough TV to have seen our ads lately).  Traditionally, SharePoint has been our delivery vehicle for document-centric processes, while BizTalk handles the system-centric side of things.  This dichotomy has been a source of confusion in many cases, and throwing Windows Workflow Foundation into the mix has added to the confusion.

Moving foward, WF will be the underlying workflow infrastructure across our products, which will help to reduce confusion, and also provide a bridge between the system-centric and document-centric approaches to workflow.  For example, consider a lending scenario that starts with an online application.  The processing logic for this loan application includes a set of BizTalk rules and orchestrations that pull in data from credit agencies and other internal systems.

Assuming that (for some reason) our rules indicate that the application requires manual review and the collection of additional documentation, we could then "drop out" of the BizTalk workflow and into a SharePoint workflow that users interact with via Office.  When we've collected all of the required documents and completed the SharePoint workflow, we could then smoothly return control to the BizTalk workflow.  Because the underlying workflow engine is the same across products, our process can span a variety of server and client products, allowing us to choose the right tool for the job at each step of our workflow.

For the inaugural entry of my new blog, I'd like to introduce myself and let you know what I'll be blogging about here.

My name is Brian Jackson, and I am an Industry Technology Strategist on the Worldwide Financial Services team at Microsoft.  This is a new role for me, and I'm really excited about working with our banking customers to help them make the most of their investment in Microsoft technology.

Some of you may know me from my previous role as "CCF guy."  In my new role, I'll still be talking about CCF when it makes sense for our FSG customers, but my technical scope will be broader, so I'll also cover many other interesting technologies, such as BizTalk, HIS, and our branch infrastructure offerings.  Initially, I'll be very focused on our Channel Renewal suite of offerings, described here.

My CCF responsibilities for non-FSG customers will be cleanly transitioned to other folks here at Microsoft who can continue to work with these customers.

This blog will be focused on Microsoft technology within the financial enterprise.  I'll track new developments in our technology stack, industry news, and try whenever possible to show the connections between the two.  I also have a poorly-maintained personal blog here, so I won't be posting pictures of my dog or any non-professional material here on my MSDN blog.

So.... let's get on with it.