American Journal of Industrial and Business Management
Vol.4 No.4(2014), Article ID:44553,7 pages DOI:10.4236/ajibm.2014.44024

Establishing Payment Hubs—Unwind the Spaghetti?

Christoph Markert

Faculty of Management, Comenius University, Bratislava, Slovakia


Copyright © 2014 by author and Scientific Research Publishing Inc.

This work is licensed under the Creative Commons Attribution International License (CC BY).

Received 13 February 2014; revised 13 March 2014; accepted 20 March 2014


Banks and financial services providers are facing a more and more competitive business within the retail banking as well as corporate market. Increasing productivity and efficiency by decreasing operational costs is very often one milestone on the strategic business roadmap of a bank or financial services providers. The payment area is usually seen as a cost intensive, but necessary part of the business and information technology (IT) landscape. Many banks and financial services providers do still follow a best-of-breed approach within the system payments landscape, which ends up in high operational and maintenance costs as different payment processing platforms are serving different business purposes. The establishment of a single globally centralized payment hub cannot be only the solution for the ending of a heterogeneous payment processing landscape, but also for supporting the strategic management roadmap by decreasing system complexity and increasing the efficiency of the payment platforms and thus decreasing operational and maintenance IT costs. Furthermore it can support banks to establish a far more flexible technological implementation approach for an entire core banking transformation program. This paper is analyzing the challenges and issues banks and financial services providers are facing with the establishment of payment hubs in their enterprise system landscape from a management as well as IT point of view.


Payment Hubs, IT Management, IT Architecture

1. Introduction

Financial Institutions all over the globe are currently focusing on increasing their efficiency in payment processing. At the first glance this is more than sensible as most retail customers don’t want to pay for any kind of standardized transaction, especially domestic transactions. Regulatory changes like the unification of the European transaction market by introducing a Single European Payment Area (SEPA) strengthen the customer’s position and are not limited to private retail customers. Even corporate customers are now eligible to initiate pan-European payments using the SEPA payments scheme without getting charged any fee—or at least at much lower fee rates [1] [2] . A few years ago, this was still a very reliable income source for payment providers and financial institutions as any kind of cross-border transaction was handled by using the SWIFT network—a global and more broaden payments scheme rather than SEPA, but also much more expensive.

However, banks do not only face the challenge of a profit source break-down [3] . As most landscapes of banks are more likely heterogeneous rather than homogenous, which is even more common in Tier-1 banks as the underlying evolution of the IT enterprise architecture was just not a primary focus in the 80’s and 90’s, the integration of the different applications and platforms is another issue and challenge in order to gain efficiency. Focusing on the payments area in particular, this kind of IT architecture usually means “Italian style” integration— point to point connections of a multi-channel front end architecture to several payment systems, which looks on an architecture design chart like Spaghetti pasta (see Figure 1).

2. Motivation

Replacing any kind of a core banking system is always a challenge for banks. Besides the transformation of different banking business domains from an IT point of view, the impact and the following business-related consequences are much more significant and extensive. The most common related and affected domains are account management, financial accounting, risk management and lending, but there is one domain, which links all these different business domains together or at least these domains rely on one centralized business cluster: Transactional Banking or Payments. In order to stay competitive in the current banking market, a reliable, scalable, highly flexible and agile system landscape and software application architecture can be one of the main business success drivers [4] . One generic core banking transformation approach could be the establishment of a centralized payment hub as an initial starting point or project/program phase. The motivation itself is based on the

Figure 1. Multiple payment processing platforms.

hypothesis, that a payment hub can support banks and financial services providers to gain operational efficiency and serve as an initial project phase for a core banking transformation program.

3. Literature Review

Banks as well as financial services providers need to stay competitive in the current banking market and thus they need a flexible and highly resilient system architecture. The design of the landscape itself should follow an integrated infrastructure design approach and be aligned with the corresponding business processes in order to provide a high quality of service [4] . The provisioning of high value and high quality services is significant for banks as it leads to an increased share of wallet with their customers due to an increased loyalty within the customer to bank relationship [5] . The quality of any kind of banking services is nowadays relying more and more on the technological infrastructure of a bank as many services—especially for the new “millennial” customer— have to be available 24/7 and virtually around the globe [6] [7] , but it is also depending on the country’s or region’s technological infrastructure [8] . Web Services can be a solution design from an integration point of view and cloud data storages from an availability perspective. According to the SOA (Service Oriented Architecture) approach, web services have to be re-usable, interoperable and business-context specific [9] . The design and implementation approach for accounting and billing related web services—especially focusing on the payment area within the corporate world—has been analyzed by MuthuLakshmi [10] . The design and implementation of a privacy preserved off-premises cloud data storage with focus on the healthcare and payment card industry has been already evaluated and could be a solution for security related concerns and issues for the transactional payment area [11] . However, there is still a lack in the current literature as these discussions are not linked in any way to the aspect and significance of the implementation of a centralized payment processing hub and the related issues and challenges banks are facing during the establishment phase from a business management and technological point of view. However, the pure management aspect of a payment transformation within banks was discussed in an interview performed by the magazine “Bank Systems & Technology” with Matt Cohan [12] .

4. Establishing a Payment Hub

In order to run the bank with a payment infrastructure consisting of different payment applications (see chapter 1, Introduction) you are facing several issues on an operational level, especially reconciliation. Besides that, the even bigger challenge is to get rid of this kind of system landscape and transform the bank to a less sophisticated payment processing architecture by streamlining all payments into one single payment hub. As easy as this sound, banks and financial services providers usually face 3 common issues.

4.1. The Transformation Phase

In order to transform a point to point—or metaphorically speaking Spaghetti like—payment processing architecture, the IT and business division have to design and align to a common roadmap strategy. Due to the fact, that the processing of payments is crucial in any kind of financial institutions a big-bang transformation approach is usually considered as high risk strategy and thus not common. However, the transformation itself will take time and is not a cheap endeavor. On the other hand you’ll increase the operational efficiency, react quicker to market challenges and changes as well as regulatory requirements. But the business benefits are marginal as the end user or the customers will benefit only marginally. Thus it will be hard to convince high level managers and CIOs/CEOs for the support of such a transformation phase in order to sponsor it, but their support is crucial for a transformation success. According to Matt Cohn, Partner in Capco’s Banking practice in North America, the transformation phase is not only a simple project, but a multi-year program:

“Most organizations are trying to sort out how to take on the transformation. Many of them see the value of hubs, but getting there in the current environment with their existing legacy infrastructure is a challenge. They have to navigate what can be a fairly complex transition and break it down to logical pieces to form a multi-generational program. [...] The regulatory environment is making it that much more difficult—there’s an internal competition for resources and dollars. [...] For example, we worked with a financial institution that recognized it has lots of redundant payment executions, and they wanted to know if there was technology to help reduce that complexity and save money. The unequivocal answer is, ‘Yes, there is.’ But unfortunately it fell down their list of priorities. The focus on regulatory compliance is one reason for that. So you have to show that there is a compelling business case to make the investment [in payments hubs]” [12] .

4.2. The SOA (Service Oriented Architecture) Paradox of de-Coupling

Payment Hubs are designed to be located at the heart of a core banking system landscape. All channels are streamlining their payments into one single processing application, which is validating, enriching and distributing the transactional payment data. In order to provide a functional feedback to a multi-channel architecture, the payment system has to provide business related information regarding the processing and posting status of each payment. This kind of architecture implicates a direct coupling of the frontend channels, the payment hub and the corresponding account management systems in order to provide a functional respond real-time or at least near-time. However, a service-based integration architecture is usually based on the philosophy of a de-coupled system integration without any direct coupling and inter-system dependencies, which contradicts from a very first point of view with the establishment of a single payment hub. The solution could be an asynchronous service behavior using a request—confirmation pattern (see Figure 2), which provides from a functional point of view the same information as a synchronous request—respond pattern (see Figure 3), but decouples each system from each other (multi-channel frontend, payment hub, account management systems) from a technical point of view.

4.3. Volumes

Due to the fact, that every single payment request triggered from all different kind of channels—real-time as well as bulk based—will be sent and processed via a centralized payment hub, the volumes in this system will be significantly higher than for a “normal” payment processing platform (e.g. payment processing platform for domestic payments only). This ends up in a demand for highly scalable and extremely flexible application

Figure 2. Request—confirm integration pattern.

Figure 3. Request—response integration pattern.

platforms in order to handle these numbers of payment requests.

Once a single payment hub is established (see Figure 4), the number of channel based interfaces as well as the integration channels to the account management backend systems will decrease significantly on a linear basis (see Figure 5). From a mathematical point of view, the number of interfaces to and from payment processing applications can be represented as the function:

Within this formula the number of interfaces f(p) are depending on the number of payment applications p, the number of channel based interfaces c to the payment applications and the number of interfaces from the payment applications to the account management systems a.

5. Conclusion

Banks and financial services providers have to face the new reality of a more and more competitive banking market situation as well as break-downs of once reliable revenue sources due to regulatory requirements, customer demands and new competitors in the industry. In order to boost their business capabilities, revenues and thus stakeholder value, banks have to provide new business strategies, cut down operational costs and increase agility. From a payment point of view Payment Hubs seem to provide a solution for these issues and challenges, but not without an investment and implementation risk as a Big-Bang approach is not a real suitable transformation strategy for most banks. As easy as it seems, unwinding Spaghetti pasta isn’t always as simple as it appears at a very first glance, but it can support the bank’s core banking business and IT strategy from a long term approach point of view.


I would like to express my special appreciation and thank you to my advisor Professor Dr. Ing. StojanRussev,

Figure 4. Centralized payment hub.

Figure 5. Calculation of integration interfaces based on number of payment processing platforms.                     

you have been a tremendous mentor for me. I would like to thank you for encouraging my research and for allowing me to grow as a research scientist. Your advice on my research has been priceless.

A sincere thank you to my family, my partner and her family. Words cannot express how grateful I am for all of the sacrifices you have made on my behalf in order for me to focus on scientific research besides my job.


  1. Williams, J. (2012) Counting the Hidden Costs of SEPA Migration—Analysis of Impact of Poor Domestic Data Migration. Experian, Nottingham.
  2. Styles, P. (2011) The SEPA Challenge. GTNews—Expert Commentary on Global Treasury and Finance.
  3. Jain, A., Yadav, R., Chawla, G. and Costanzo, C. (2012) World Retail Banking Report. Capgemini and EFMA.
  4. Sinha, S., Hartmann, D., Brill, J., Suarez, P. and Kumaran, S. (2011) Core Banking Modernisation. In: Smarter Planet, IBM Financial Services—Point of View, IBM Australia, West Pennant Hills.
  5. Markert, C. (2013) Analysis of Key Trends in the Banking Area—Is IT Going to Be the Game Changer No. 1? In: Marosi Verlag, Scientia Nova—Das Interdisziplinaere Wissenschaftsmagazin, Vol. 17, Institute for Academic Cooperation, Mannheim.
  6. Maguire, A., Chin, V., Desmangles, L., Kurstjens, H., et al. (2010) Global Retail Banking 2010/2011—The Road to Excellence. Boston Consulting Group, Boston.
  7. Lewis, S. (2012) Making the Right Moves—Global Banking Outlook 2012-13. Ernst & Young, New York.
  8. Mastercard (2012) The Mobile Payments Readiness Index: A Global Market Assessment. Mastercard Worldwide, New York.
  9. Erl, T. (2005) Service-Oriented Architecture: Concepts, Technology and Design. Pearson Education, London.
  10. MuthuLakshmi, V. and Anand, S. (2012) A Generic Charging Policy Based Accounting for Web Services. Journal of Computer Science, 8, 1455-1466.
  11. Brohi, S.N., Bamiah, M.A., Chuprat, S. and Manan, J.A. (2014) Design and Implementation of a Privacy Preserved Off-Premises Cloud Storage. Journal of Computer Science, 10, 210-223.
  12. Yurcan, B. (2011) Payment Hubs: Better Late Than Never. In: Bank Systems & Technology, UBM LLC, New York.