Financial Services

More Than You Want to Know About State Street Bank’s Technology Strategy Part 2

This article is a continuation of my earlier analysis (Part 1 here) where I waded into State Street’s strategy for Technology Infrastructure and IT Capability and Staffing. In this second part of my three part series I will broach the company’s strategy for information risk and security, stakeholder requirements and project return on investment. State Street’s cloud implementation and virtualization initiative is a good example of business strategy/need influencing the firm’s information technology strategy.

State Street: Strategy for Information Risk & Security:

State Street has acquired a substantial client base and houses sensitive financial data that is subjected to regulatory scrutiny. Given the sensitive nature of its data and operations, the cloud infrastructure that the bank chose to implement was that of a virtualized private cloud. Former Chief Innovation Officer Madge Meyer stated, “We’re totally virtualized, our network is a virtual private IP network. Our servers are 72 percent virtualized and our storage is all virtualized for structured/unstructured data” (Burger, 2011). For State Street, a private cloud offers the benefits of a public cloud with the added benefit of being owned and operated by the bank (i.e. exclusive dedication). While no architecture is 100% secure, the risk of an information breach is mitigated as the controlling organization’s data can be completely isolated from the data of another organization.

Additionally, the cloud implementation and virtualization initiative gave rise to shared services that are centrally managed but enforced across the enterprise. This single security framework can be applied across all of the application touch points precluding the need for multiple security frameworks across disparate systems.

State Street: Strategy for Stakeholder Requirements, Testing & Training/Support:

The architecture group within State Street works together with the business to tie together strategic objectives. The idea to embrace cloud implementation (and the additional data functionality it enabled for the bank’s clients) emanated in the architecture group. Thus, the business and the board of directors were key stakeholders in the initiative. The board of directors has a special dedicated technology committee that receives “a complete rundown of the technology strategy and the work that we (IT group) are doing in terms of digitizing the business” (High, 2016). According to Perretta, “They (architecture group) created a proof of concept with an eye toward: Here are the capabilities that our entire organization is going to need, here are the technologies that we can deploy, and here’s how to make them operational” (Camhi, 2014).

State Street started migrating its new cloud applications to production by selecting those with low volume and low complexity and then gradually ramped up to migrating the more complex applications (McKendrick, 2013). Dual pilots of the cloud architecture were conducted using roughly 100 machines. Once favorable results were achieved, a larger pilot consisting of 500 machines was stood up. Approximately 120 use cases were tested in the pilot in order to let the development team understand the failure points of the system (Tucci, 2011a).

The standardization and virtualization aspects of the cloud infrastructure the bank implemented was conducive to agile development. Virtual machines on the cloud allowed development teams to spin up multiple server instances as opposed to physically installing a new box in the legacy non-virtualized environment. Contention between teams waiting for server use is virtually eliminated. “When adding cloud computing to agile development, builds are faster and less painful, which encourages experimentation” (Kannan, 2012). The relative ease at which development and testing servers can be instantiated promotes “spur of the moment” experimental builds that could yield additional innovative features and capabilities.

State Street: Project ROI and Key Success Measures:

Prior to State Street’s cloud infrastructure upgrade initiatives, potential operating cost savings were projected to be $575 million to $625 million by the end of 2014; which State Street is on track to achieve. “The bank had pretax run-rate expense savings from the initiative of $86 million in 2011, $112 million in 2012, and $220 million in 2013” (Camhi, 2014).

When the IT group makes a budget request for substantial investments, they must lay out the potential benefits to the business. Some of the benefits are timely payback, regulatory compliance, data quality improvement and faster development cycle times (providing features and functionality with re-use and less coding). The ultimate aim is to connect the IT strategy to business results in a way that yields advantage for the organization.

In 2011, State Street published a matrix on the advantages of cloud computing vs. traditional IT. The following figure provides insight into State Street’s IT and business unit considerations with respect to making an investment in a fixed or variable cost infrastructure (Pryor, 2011).

Traditional IT Cloud Computing
Cash Flow Hardware / software purchased upfront Costs incurred on a pay-as-you-go basis
Risk Entire risk taken upfront with uncertain return Financial risk is taken incrementally and matched to return
Income Statement Impact Maintenance and depreciated capital expense Maintenance costs only
Balance Sheet Impact Hardware / software carried as a long-term asset Cost incurred on a pay-as-you-go basis

From a funding perspective, State Street employs the chargeback funding method for its private cloud initiative. Architectural capabilities empower end-users to automatically provision virtualized servers for usage. There are policies in place that determine how long a virtual server may remain instantiated and how much load balancing is performed across the infrastructure. Server usage is monitored, measured and chargeback is calculated based upon end-user processing time. Subsequently, the usage is billed back to the end-user’s respective business unit. “In short, it puts a management layer of software over the virtualized servers and operates them in a highly automated, low touch, fashion” (Babcock, 2011).

References:

Babcock, C. (November 9, 2011). 6 big questions for private cloud projects. Information Week. Retrieved from Factiva.

Burger, K. (October, 1, 2011). Riding The Innovation Wave; Technology innovation has been key to State Street Corp.’s success, according to chief innovation officer Madge Meyer — and she’s been willing to take some risks to prove it. Bank Systems + Technology. Retrieved from Factiva

Camhi, J. (2014). Chris Perretta Builds Non-Stop Change Into State Street’s DNA. Bank Systems & technology. Retrieved from http://www.banktech.com/infrastructure/chris-perretta-builds-non-stop-change-into-state-streets-dna/d/d-id/1317880

High, P. (February 8, 2016). State Street Emphasizes Importance Of Data Analytics And Digital Innovation In New Role. Retrieved from http://www.forbes.com/sites/peterhigh/2016/02/08/state-street-emphasizes-importance-of-data-analytics-and-digital-innovation-in-new-role/#a211b1320481

Kannan, N. (August 20, 2012). 6 Ways the Cloud Enhances Agile Software Development. CIO. Retrieved from http://www.cio.com/article/2393022/enterprise-architecture/6-ways-the-cloud-enhances-agile-software-development.html

McKendrick, J. (January 7, 2013). State Street’s Transformation Unfolds, Driven by Cloud Computing. Forbes. Retrieved from http://www.forbes.com/sites/joemckendrick/2013/01/07/state-streets-transformation-unfolds-driven-by-cloud-computing/#408e1acf64cf

Tucci. L. (July, 2011a). In search of speed, State Street’s CIO builds a private cloud. Retrieved from http://searchcio.techtarget.com/podcast/In-search-of-speed-State-Streets-CIO-builds-a-private-cloud

More Than You Want to Know About State Street Bank’s Technology Strategy Part 1

Introduction:

In November of 2010, Investment Management firm State Street Bank publicly announced an overall transformation of its technology infrastructure. State Street is a massively sized transaction services provider to both mutual and pension fund managers. The custodian bank holds $23 trillion in investor accounts in 29 countries around the world. In an organization with a massive store of data (most of it subjected to regulatory oversight), enterprise wide data conformity and accessibility is a challenge.

In a case of business strategy/need influencing information technology strategy, State Street’s COO in 2009 (Jay Hooley) wanted to help an institutional client calculate its exposure to a particular market. The information request was highly urgent given the financial consequences of late reactions during the great recession. “Getting the numbers turned into a painful exercise as State Street’s middle- and front-office staffers reconciled disparate data sets housed in different client systems and in nine of State Street’s 29 global locations” (Fest 2013). This failure to deliver for the client in an instantaneous manner spurred Hooley to call upon his information technology leadership to present a strategy to address this business need. The result of the IT leadership planning effort was the idea to move the bank’s diverse legacy infrastructure to a more standardized and nimble cloud computing architecture.

State Street: Strategy for Technology Infrastructure:

Former State Street CIO Chris Perretta, who as of 2016 holds a similar position at MUFG America’s Holdings Corporation, spent a considerable amount of time evangelizing the benefits of cloud computing to both the business and the bank’s board members. In its early stages, the technology vision resulting from the COO’s planning request was to position an updated infrastructure as a competitive advantage for the business in terms of cost savings, automation, and future development efficiency. Furthermore, the updated infrastructure could be an enabler of new product revenue streams. It should be noted that a shift to the cloud for a financial organization the size of State Street was unusual. “Too Big to Fail” sized banks are not typically known for their innovative technology development. Derisively, the bank has been known as “Staid Street” for its conservative manner. Within financial services, innovation is usually the domain of smaller, nimbler “fintech” startups looking for scalability and speed to market.

From an infrastructure perspective, State Street embarked upon migrating from disparate legacy data centers running proprietary Unix servers to a standardized cloud architecture based upon commoditized x86 servers running Linux. The initial cloud service was built from a Massachusetts based disaster recovery center and the bank currently has six major data centers in the U.S., Europe and Asia along with three backup facilities (Brodkin, 2011). In addition to the rollout of virtualization capabilities and distributed database functionality, Perretta states, “New tools for provisioning, change control, load balancing, a common security framework and various types of instrumentation to enable multi-tenant infrastructures are all part of the mix” (Brodkin, 2011).

Traditionally State Street has relied upon the “build rather than buy” approach as it builds customized software (development traditionally accounting for ~20%-25% of annual IT budget) to meet its needs (CMP TechWeb, 2012). The standardized cloud platform now enables developers to reuse code for future development which can shorten project timeframes.

State Street: Strategy for IT Capability & Staffing:

State Street’s IT organizational structure can be characterized as federalism. With the federalist approach, the organization gains the benefit of having centralized leadership and vision at the “top of the house”, yet allows decentralized co-located IT groups to remain responsive to their respective divisions. As described by former CIO Perretta, “We line up delivery capacity with each unit, and each CIO is responsible for delivering business services to that unit” (MacSweeney, 2009). For example, The CIO has a direct report on the ground in China where the company operates a subsidiary (State Street Technology Zhejiang Co). Furthermore, the bank is tolerant of “skunk works” style projects that organically develop in different IT divisions throughout the enterprise (MacSweeny, 2009).

On the centralized side of the federalist equation, the bank operates a shared services group that is responsible for technical necessities distributed throughout the enterprise (i.e. security, information and communications). This federalized approach makes sense for a sprawling organization that is comprised of disparate business operations across its custodian bank, investment management, investment research and global divisions.

With the introduction of the cloud infrastructure at State Street, the technology staffing vision is to acquire individuals with architectural knowledge who can think “big picture” yet are able to wallow in the details as necessary. The bank employs a chief architect whose aim is to drive technology innovation that leads to strategies that will impact the business in an advantageous manner. Perretta states, “We don’t use him to manage projects; we use him to come up with the ideas that make sense for our business community. Now he does those pilots, and then we industrialize them for the rest of the organization” (Tucci, 2011).

To be continued in Part 2 and Part 3 where I address additional areas such as:

  • Strategy for Information Risk & Security
  • Strategy for Stakeholder Requirements, Testing & Training/Support
  • Project ROI and Key Success Measures
  • Strategy for Data Acquisition and Impact on Business Processes
  • Strategy for Social Media/Web Presence
  • Strategy for Organizational Change Management, Project Strategy and Complexity

References:

Brodken, J. (April, 14, 2011). State Street modernizing with cloud, Linux technologies; Virtualization, open source drive cloud project at State Street. Network World Fusion. Retrieved from Factiva 6/19/2016

CMP TechWeb. (June, 25, 2012). State Street Private Cloud: $600 Million Savings Goal. Retrieved from Factiva 6/19/2016

Fest, G. (January 1, 2013). State Street’s Dig (Data); Championed by CEO Jay Hooley, boston-based state street is remapping a huge technology infrastructure to reap the benefits of the cloud and big data. American Banker Magazine. Vol.123, No.1. Retrieved from Factiva

MacSweeney, G. (August, 1, 2009). Serious Innovation; CIO Christopher Perretta supports all of State Street’s IT needs by mixing new technologies and rapid development and even encouraging ‘skunk works’ experimentation when appropriate. Wall Street & Technology. Retrieved from Factiva

Tucci. L. (July, 2011). In search of speed, State Street’s CIO builds a private cloud. Retrieved from http://searchcio.techtarget.com/podcast/In-search-of-speed-State-Streets-CIO-builds-a-private-cloud

Photo courtesy of DAVID L. RYAN/GLOBE STAFF

Consumer Financial Protection Bureau Infographic: Complaints Analysis

Background

As a data and visualization endeavor, I put together an infographic that highlights some product complaints analyses I performed using publicly available Consumer Financial Protection Bureau data.

In case you are unfamiliar with the CFPB, it is an organization that was created in 2010 as a result of the financial calamity that gripped that nation during the great recession. The CFPB’s mission is to write and enforce rules for financial institutions, examine both bank and non-bank financial institutions, monitor and report on markets, as well as collect and track consumer complaints.

On the bureau’s website they host a consumer complaint database that houses a number of complaints that consumers file against financial institutions.

Each week we send thousands of consumers’ complaints about financial products and services to companies for response. Those complaints are published here after the company responds or after 15 days, whichever comes first. By adding their voice, consumers help improve the financial marketplace.

Process

I downloaded the complaint database from the CFPB’s  website and then decided to concentrate on selected bank complaints from the many financial institutions that are present in the database. I settled on a self-defined “National” category and a “Regional” category and then analyzed the percentage of complaints across three product spaces (Mortgages, Bank Accounts & Credit Cards).

I felt a percentage approach would be more useful than just merely listing a total count of complaints. The national banks category consists of the four nationally known firms: JP Morgan Chase, Wells Fargo, Bank of America and Citibank. The regional banks category consists of ten fairly large regional banks that have product offerings similar to the national banks.

It’s fairly obvious that the behemoth national banks are going to have more mortgage complaints than the much smaller regional banks on a total count basis. The more interesting analysis is to look at the rate of mortgage complaints for the national banks as compared to the regional banks (e.g. divide a specific product complaints total like mortgage by the total complaints for all products; calculate this percentage for national and regional categories across all three products).

I carried out this analysis using the ggplot package in R to generate the base graphics for the infographic. Adobe Illustrator was then used to further refine the graphics into what you see below:

IST 719 Final Project-01_BLOG_VERSION

I have an additional unrefined chart that is a straight output from the ggplot package in R. I didn’t have enough space on the infographic to include it there. However, this analysis is the same as is represented in the bottom quadrant of the infographic, except that it solely applies to regional banks.

The analysis consists of totaling all of the specific PRODUCT complaints filed against a particular bank and then dividing that number by the total number of ALL complaints filed against the individual bank (e.g. Total mortgage complaints filed against a bank/total complaints filed against a bank). I call the resulting number the Complaint Ratio.

In the ggplot graph output below we can see that Regions’s “Bank Account or service” product represents about 67% of all complaints filed against Regions. If I were to break out the numbers on a total count basis, we’d see that Regions’s overall complaints total is relatively small compared to other banks. However, the bulk of its complaints are distributed in the “Bank Account or service” product area.

9_Regional Data by Product

May your next bank be your best bank.

Additional Reading:

An Interesting Comparison of Bank of America to JPMorgan Chase

The Benefits of Service Oriented Architecture for Financial Services Organizations

The banking and financial industry is an industry where legacy systems are prevalent. Banking systems tend to skew older and are very heterogeneous in nature. This heterogeneity of legacy banking systems is also coupled with the fact that replacement and integration of these systems is a difficult undertaking.

Mazursky (as cited in Baskerville, Cavallari, Hjort-Madsen, Pries-Heje, Sorrentino & Virili, 2010) states that older architectures complicate integration of enterprise applications because the underlying elements have created ‘closed’ architectures. Closed architectures restrict access to vital software and hardware configurations and force organizations to rely on single-vendor solutions for parts of their information computer technology. Thus, closed architectures hinder a bank’s ability to innovate and roll out new integrated financial products.

The flexibility of SOA facilitates easier connectivity to legacy backend systems from outside sources. Because of the size and complexity of most enterprise banking systems, a potential reengineering of these systems to flawlessly accommodate interaction with newer systems is not economically feasible. Inflexible systems can be difficult to modernize and maintain on an on-going basis. Furthermore, banks’ legacy systems can suffer from a lack of interoperability, which can stifle innovation.

“According to a survey commissioned by Infosys and Ovum in May 2012, approximately three quarters of European banks are using outdated core legacy systems. What’s more, 80% of respondents see these outdated systems as barriers to bringing new products to market, whilst 75% say such systems hinder, rather than enable, process change. Integration cost is effectively a barrier to service provision flexibility and subsequent innovation” (Banking Industry Architecture Network, 2012).

The greater the number of banking systems that can easily interact, connect and share data with other systems and services, the more innovative banks can become with respect to their product offerings for consumers. Market demands can be more easily responded to when new product creation is allowed to flourish with appreciably lower system integration costs. New applications can also be developed in much shorter time frames in order to react to customer demand as long as services are maintained and shared across the enterprise.

According to Earley & Free (2002), a bank that identifies a new business opportunity such as wealth management but has never provided such a service in the past can quickly ramp up functionality by utilizing services previously designed for other applications. The new wealth management application is designed without duplicating functionality in a more cost efficient and rapid manner. Smaller and mid-tier banks can capitalize on bringing new applications and services to market quickly and economically. This responsiveness allows smaller banks to offer similar products as those offered by their larger competitors. The modularity of SOA design precludes the need for substantial re-engineering of smaller/mid-tier banks’ information computer technology. This is an important benefit because smaller banks do not have comparable financial resources with respect to the more sizable industry players.

Additionally, SOA has the potential to free up development resources sooner, enabling those resources to engage in other development initiatives. “Few banks will be able to buy or build new capabilities quickly enough to satisfy market requirements without an SOA” (Earley & Free, 2002). In the survey conducted by Infosys Consulting and Ovum (a London based research organization), 100% of banks responded that SOA would become the “dominant, accepted future banking architecture“ (Banking Industry Architecture Network, 2012).

Furthermore, banks can employ multiple services to complete a business process. One service that determines the value of a portfolio of financial assets at market rates (mark to market calculations) could be coupled with another service that calculates the Value at Risk (VaR) of the bank’s entire portfolio. In a similar fashion to the new wealth management application example previously cited, the dual components could be made available to many other enterprise wide financial services and applications that require portfolio valuation and risk related information. In this manner, the functionalities are not inefficiently repeated across every application where they are requested.

Additionally, via use of SOA, “New technology provides the ability to mix and match outsourced business processes with on-premise assets and services” (Essvale Corporation Limited, 2011). Software designed or in use by third party vendors can become more easily integrated with bank systems and processes due to the high connectivity of an SOA approach. According to Gartner research, smaller and mid-tier banks are adopting SOA in order to make the most of their limited IT budgets and resources. “Until now, midtier banks had to rely on customized software packages from a single vendor, and assumed all of the maintenance costs and function limitations inherent in a single, proprietary set of solutions” (Earley et al., 2005). Due to a rising interest in SOA, technology vendors that serve the financial services industry are increasingly working with integration providers to offer a standard set of component integration (Earley, et al., 2005).

One of the benefits of SOA standardization is the enablement of more functionality, performed by much less underlying code. This leads to less complex, more cost effective system maintenance; thereby reducing operational risks.

“A fully implemented SOA provides a bank with a highly predictable application environment that reduces risk in day-to-day operations, due to the minimization and isolation of change to the production systems. Banks that fail to take this approach must constantly change their interfaces as external and internal requirements change. This introduces significant risk and the need for near-continuous testing to ensure that the customer ‘touchpoints’ and the back-end processes do not fail, while ensuring that one data or service change doesn’t adversely affect other data changes integrated through an interface” (Earley et al., 2005).

Conclusion

SOA has an important role to play in the architectural repertoire of banking and financial organizations. Its loosely coupled design characteristic allows services to be shared and reused across the enterprise without disparate systems concerning themselves with the underlying development code. Multiple services can be combined together to form reusable chunks of a business process. Outside sources can connect to legacy backend systems via an API, which increases the opportunity to mix and match vendor capabilities with in-house assets. SOA also helps banks and financial firms ramp up new applications and functionality quickly and economically, increasing product responsiveness to market demands. When SOA is combined with Event Driven Architecture, dynamic event driven systems can be developed that do not rely solely on the less proactive request/reply paradigm.

Banks and financial companies need to remain innovative, cost effective and anticipate customer needs in order to remain profitable. SOA allows organizations to become more agile and flexible with their application development. The rise of applications on mobile cloud enabled platforms means that customers will need to connect to data wherever it dwells. “Bank delivery is focused on reactively providing products on customer request, and mass-market, one-size-fits-all products (for mainstream retail banking). However, it is no longer feasible to force-fit mass-market bank products when technology devices, context and location are key elements to the type of customized bank service a customer needs” (Moyer, 2012). As SOA continues to mature with cloud enabled solutions and the rise of mobile computing, it is primed to be the building block for the next generation of banking application functionality.

References:

Baskerville, R., Cavallari, M., Hjort-Madsen, K., Pries-Heje, J., Sorrentino, M., & Virili, F. 2010. The strategic value of SOA: a comparative case study in the banking sector. International Journal of Information Technology and Management, Vol. 9, No. 1, 2010

Banking Industry Architecture Network. (2012). SOA, standards and IT systems: how will SOA impact the future of banking services? Available from https://bian.org/wp-content/uploads/2012/10/BIAN-SOA-report-2012.pdf

Early, A., & Free, D. (2002, September 4). SOA: A ‘Must Have’ for Core Banking (ID: SPA-17-9683). Retrieved from Gartner database.

Early, A., & Free, D., & Kun, M. (2005, July 1). An SOA Approach Will Boost a Bank’s Competitiveness (ID: G00126447). Retrieved from Gartner database.

Essvale Corporation Limited. (2011). Business knowledge for it in global retail banking: a complete handbook for it professionals.