Journal of Internet Banking and Commerce ISSN: 1204-5357
ISSN: 1204-5357
+44-175-271-2024| Zilvinas Bareisis |
| Zilvinas Bareisis Senior Analyst, Celent Postal Address: 55 Baker Street, London, W1U 8EW, UK Author's Personal/Organizational Website: www.celent.com Email: zbareisis@celent.com Zilvinas Bareisis, MSIA, MSc, is a Senior Analyst within Celent's Banking group and is based in London. Mr Bareisis's research focus is on payments, particularly cards, processing, and innovative retail and corporate payment propositions. |
Visit for more related articles at Journal of Internet Banking and Commerce
Payment services hub concept is gaining ground as an accepted way forward to modernizing banks’ payments architectures. However, the confusion over definitions and terminology remains. This paper proposes a visionary definition of a payment services hub and clarifies the key terms. It also describes the four types of payment services hubs banks are currently implementing in practice.
Keywords |
| banking; information and communication technology (ICT); payment services hub; research study |
TABLE OF CONTENTS |
| 1. Introduction |
| 2. Payment Services Hub: What Is It After All? |
| 2.1. Scope |
| 2.2. Core Functionality |
| 2.3. Technology Architecture |
| 3. Payment Services Hubs in Practice |
| 3.1. Channel Integration Hub |
| 3.2. CSM Integration Hub |
| 3.3. Payment Orchestration Layer |
| 3.4. Vertical Payment Services Hub Solution |
| 4. Additional Terminology Considerations |
| 5. Conclusion |
1. INTRODUCTION |
| Over the last few years, the concept of payment services hubs (PSH) has been promoted by technology vendors and industry analysts as the leading approach to modernising banks’ payment infrastructures. |
| There is certainly a noticeable increase in interest and activity among banks in upgrading the payments infrastructure. However, if one talks to industry participants, it quickly becomes obvious that there is more work to be done to get everyone to speak the same language and to agree on the key definitions. “Payment services hubs,” “payment engines,” “payment factories,” and other terms seem to be used interchangeably. Why is it so difficult and why can’t we all agree? |
2. PAYMENT SERVICES HUB: WHAT IS IT AFTER ALL? |
| The payments technology landscape within any given bank is often very complex, with aging legacy solutions, fragmented by payment type, currency, clearing mechanism, etc. In many cases, banks have more than one system per instrument, given that many banks have grown through acquisitions and kept multiple systems or operate internationally and need to maintain links to different Clearing and Settlement Mechanisms (CSMs). As a result, payments infrastructure is often described as “spaghetti architecture”—many-to-many direct connections between channels, payment systems, and CSMs. |
| Lately, banks have come under increased pressure to deal with these “spaghetti” payment architectures. The most common drivers include the following: |
| • Efficiency and cost reduction for both the bank and its customers: |
| • For the bank, for example, through reduction in point-to-point connections which have to be maintained or decommissioning of the legacy systems |
| • For the customer, for example, through the ability to determine/create the lowest cost payment methods, such as transaction aggregation for batch settlement, net settlement between “on-us” transaction parties, parsing batch and real time transactions (or a combination thereof) |
| • Improved payments visibility, both for liquidity management and for broader risk management and customer service. |
| • The need to deal with new payment standards and regulatory requirements. |
| • The need for faster time to market and easier adoption of new technologies, such as contactless or mobile. |
| • The need to handle the ever-growing volumes of payments with an increasing share of near-real time transactions. |
| The hub concept in payments is not a new idea. Many banks have attempted over the years to centralise their payment operations, often by geography. Some banks also point to their payment factories or shared services platforms as a way to gain efficiencies in payment operations. |
| However, a true payment services hub is a fundamentally different approach to architecting a payments solution and is not just simply a centralisation of the existing infrastructure. When fully implemented, it becomes the heart of all payments activity in the bank by: |
| • Managing the payment-related interfaces with external and internal entities, such as client systems, channels, and clearing networks |
| • Defining the rules how various payments are processed within the bank. |
| • Capturing payment information and using it to drive the payment processing. |
| • Providing capability to process payment transactions. |
| • Generating valuable information about the payments going through the bank. |
| • Interacting with other systems in the bank by drawing on their capabilities if necessary and offering payment services and payment information to others as needed. |
| Celent’s vision for a payment services hub is described in a figure below. A full payment services hub must have the following characteristics: |
| • Capable of processing any payment on a single platform, irrespective of an instrument type, value of payment, customer, channel, or transaction type (A— scope) |
| • Delivers core payment processing functionality for each of those scenarios (B— core functionality). |
| • Is built on a modern architecture (C—technology architecture). |
| • Is SOA-compliant and delivers the required functionality as services, drawn from and available to the PSH or other areas in the bank. |
| • Allows customisation of workflow by any dimension of A or payment characteristics, such as value or status, and makes use of the business process management (BPM) tools, whether in-house or third party. |
| • Has Business Activity Monitoring (BAM) capabilities, including alerting and reporting, again delivered either within the solution or through integration with third party offerings. |
| • Reliable at large volumes and throughput. |
| • Has appropriate security, access control, and audit trails. |
 |
| The following sections examine this definition in more detail. |
2.1. SCOPE |
| The visionary payment services hub should be able to manage any type of payment through a single platform. That includes: |
| • Instrument type: |
| • Credit transfers, including high and low value, domestic and international, including SEPA Credit Transfers |
| • Direct debits, including SEPA Direct Debit |
| • Various cards, including credit, debit, and prepaid |
| • Cheques and any other types of payment |
| • Channel: host-to-host connectivity, file input, online (both retail and commercial) and mobile transactions, instructions from the branch, ATM and POS transactions, and other. |
| • Customer: corporate clients (large and SME), retail clients, other financial institutions, and bank internal departments generating payment instructions (e.g., Treasury, Trade Finance, etc.). |
| In addition, the solution should be capable of handling multiple transaction types— outgoing and incoming payments, single and batch, and various R-type transactions (Reject/Refusal/Return/Refund/Request for Cancellation/Reversal). It should also be able to deal with mixed files (i.e., customer files that contain multiple types of payment instructions). |
| Finally, the solution needs to be able to connect to and process payments according to the rules and messaging standards of multiple Clearing and Settlement Mechanisms and networks, including multiple RTGS and ACH systems, card networks, SWIFT, STEP2, and others. |
| For each of these transactions, the PSH should be able to take and handle as rich a data set as it is provided by the instrument and channel (e.g., card level 2 information or ACH appended messages). Such information doesn't affect payment settlement as such, but is usually significant in the broader context (client reconciliation, workflow, etc.). |
| Most of the PSH solutions available in the market focus on processing various types of credit transfers and debit payments from multiple channels and customers. As a rule of thumb, card processing (and corresponding channels, such as ATM and POS) tends to remain on separate infrastructures, although there are some examples where card payments are being integrated onto the same payment services hub. In most of those cases, the real time switch and authorisation component remains separate and is treated as a channel which generates card transactions for clearing and settlement over the PSH. |
2.2. CORE FUNCTIONALITY |
| A true payment services hub needs to be able to support all the core payment processing functionality throughout the entire lifecycle of a payment transaction (see Figure below). Not all services will be required for all transactions, and the order may not be as it is described below; what exactly is used and in what order for a particular transaction is determined by the workflow management discussed in the Technology Architecture section. |
 |
2.2.1. Instruction Receipt and Payment Object Creation |
| Payment instructions can be generated by customers directly as they make payments to their counterparties, as a result of a customer process within the bank (e.g., a trade finance transaction) or by a bank itself (e.g., to pay salaries to bank employees). They also come in through a variety of channels (e.g., Internet, telephone banking, direct link to an ERP system, etc.) and can be electronic or paper-based (e.g., letter). A single file, such as payroll, may contain multiple instructions. In addition, these can be new payment instructions or rejected payments. |
| A payment services hub typically includes payment gateways and adapters that are able to capture all the different payment messages as described above. This is also the step where the messages are decrypted and bulked or debulked as necessary. |
| The reason most payment services hubs are able to process any type of payment is because they use a canonical payment object. Any message or instruction that comes into the PSH is transformed into an XML-based data object, often based on the ISO 20022 standard. This payment object is then sent through all the relevant steps for processing. |
| The object is sufficiently broad to contain all the necessary data elements to cover all channels and transaction types. At the end of processing, the adapters again translate that payment object into the appropriate message format for a required Clearing and Settlement Mechanism. |
2.2.2. Validation, Compliance, Repairs, and Storing |
| The party initiating the payment transaction needs to be authenticated (PIN, online password, etc.) and checked against the bank’s records to satisfy Know Your Customer requirements. Other regulatory compliance checks (e.g., Office of Foreign Assets Control lists) should be made against all parties to prevent money laundering and transfers to known criminals, terrorists, etc. Some vendor solutions come with a comprehensive validation functionality, although typically these services are common across the bank rather than payment-specific, and the payment services hub needs to be able to call upon these services. The ability to comply with local and regional regulatory requirements is a key part of the PSH offering. |
| The payment services hub should also check the messages for completeness and compliance with expected payment standards (e.g., International Bank Account Number [IBAN], Bank Identified Code [BIC], payment scheme rules, direct debit mandates, etc.). It should seek to repair the messages automatically using the internal and external data reference sources and payment repair functionality. The best payment repair services deploy sophisticated techniques, such as artificial intelligence to enhance straightthrough processing (STP). In cases where automatic repair is not possible, the payment object needs to be repaired manually. |
| Finally, if the payment does not need to be executed immediately, it will be stored in a “payment warehouse” until the due date. |
2.2.3. Clearing Preparation (CSM Selection) |
| A payment services hub needs to be able to identify and separate out the “on-us” transactions (i.e., those cases where both the sender and the beneficiary have the accounts at the same bank). For all others, the decision needs to be made about the choice of a Clearing and Settlement Mechanism. In some cases, this will be determined by the payment type (e.g., a domestic ACH for a low-value domestic transfer). Where choice is available (e.g., Fedwire vs. CHIPS in the US or multiple CSMs for SEPA payments), the payment services hub needs to be able to make the decision based on various factors, such as speed (i.e., required clearing date), cost, agreed service levels with the customer, and the bank’s liquidity position with a given CSM. |
| Bank liquidity check is an increasingly important step, as more transactions migrate toward real time. Near-real time settlement is required not only for traditional Real Time Gross Settlement Systems (RTGS), but increasingly for other CSMs, such as faster payments in the UK. Again, it is expected that liquidity management will be a common service within the bank, and the payment services hub needs to be able to call that service. |
| Payment enrichment involves adding information to the payment object depending on the chosen CSM (e.g., nostro account details for a correspondent banking payment) or depending on the specific customer requirements. |
2.2.4. Authorisation |
| Authorisation ensures that the customer has funds available to make the payment and that the bank is happy to make the payment. If the payment is in a different currency, the FX rate is determined by checking against a standard daily rate of the bank, any special agreements with the customer, or directly with the bank’s FX department. While the FX rate is likely to be provided by a common bank service, the payment services hub needs to apply the rate to convert the amount and reach out to the core banking system to check the resulting amount against the customer account balance or pre-agreed credit or overdraft limits. |
| The limits can vary depending on the channel—for example, most banks would cap the withdrawal of cash at the ATM to either a customer account balance or a predefined limit, whichever is lowest. Cash withdrawal at the branch is typically limited only by the availability of funds in the customer account, even though the same debit card is used in both cases. Given that the payment object carries the channel data, the payment services hub is able to apply processing intelligence at the appropriate steps. |
| What happens when there are insufficient funds usually depends on the customer type and the bank’s internal policies. A bank typically would contact the larger companies to discuss how to proceed rather than reject the transaction outright. Finally, many banks have a “four-eyes” policy to authorise payments, particularly larger ones; two of those eyes can be an automated decisioning system, but large payments are often reviewed by a person to ensure correct amounts and recipient details and to check for the counterparty risk. An important role of the payment services hub is to apply intelligence to orchestrate an appropriate set of actions. |
2.2.5. Execution |
| Execution is all about sending the payment instruction into the interbank payment system (i.e., the chosen CSM) and applying the right entries to the customer accounts. A payment services hub should check the transactions against duplication, check the availability of the chosen CSM, and schedule the payment to be executed, taking into account any predefined priorities. If necessary, a batch file will be created. When ready, the payment gateways and adapters will translate the canonical payment object into the correct message format and deliver it to the chosen CSM. |
| When the settlement confirmation is received, the payment services hub applies the correct fees for the transaction and ensures that the relevant account entries are made. Again, pricing can either be a common service across the bank for all types of transactions, or specific to payments and therefore maintained within the payment services hub. The hub itself is not going to post the account entries but needs to instruct the appropriate systems (e.g., core banking) to book the transaction. |
2.2.6. Customer Notification and Reconciliation |
| Customers usually get the advice that their payment has been made, either after each individual transaction (typically for large value payments), at the end of the day (usually for companies), or via an end of month statement for consumers. By making payments more transparent, payment services hubs give banks and their customers an opportunity to increase visibility into their payment flows during the processing cycle, not just at the end. |
| The reconciliation needs to be done with all the different parties involved—the customer, the CSM, various internal departments—and typically is a source of labour-intensive activity. Again, payment services hubs give the opportunity to improve the process because of a richer transaction data available. |
2.3. TECHNOLOGY ARCHITECTURE |
| A true payment services hub needs to be built on a modern technology architecture. Celent’s view on the key requirements is shown in the definition Figure and discussed below. |
2.3.1. Functionality as Services (SOA) |
| The first technology architecture-related requirement in Celent’s definition of a visionary PSH states that the payments functionality needs to be “delivered as services, drawn from and available to the PSH or other areas in the bank (SOA).” |
| A payment services hub should use a modern service-oriented architecture (SOA) delivering common and reusable payment services. It needs to be architected to operate within an enterprise SOA environment and should use standard J2EE, database, and integration technologies. Modern solutions tend to be hardware-neutral and can operate on mainframe, Unix, and Windows servers and various corresponding operating systems. |
| The solution needs to be flexible and let the bank define the boundaries of what is going to reside within the payment services hub and what will be delivered elsewhere. For example, as discussed above, some functionality is not payments-specific and ideally should be delivered as a common service across the bank (e.g., OFAC checking). On the other hand, core banking systems also typically have payment processing functionality as well as deliver payment-relevant services (e.g., account posting). Finally, some banks may have developed specialist components (e.g. payment repair) which they would like to re-use in the new solution. |
| The solution should not force the bank to use the built-in functionality. It needs to be able to call on other services and functionality in legacy systems and needs to allow the bank (or a third party) to build and deploy its own components into the payment services hub. Similarly, the solution needs to provide open access to payments flow at any stage to notify other bank systems and allow them to call payment services as necessary. By using a common language within the payment object (e.g., “destination currency” means the same thing irrespective of the channel, customer, or payment type), the other systems at the bank (e.g., channel solutions) can incorporate payments data and functionality as required. |
2.3.2. Workflow Orchestration |
| The next technology architecture-related requirement in Celent’s definition of a visionary PSH is the “ability to customise workflow by any dimension of A or payment characteristics, such as value or status (BPM)”. |
| This is another key requirement in order to fulfil the vision of processing any type of payment on a single platform. Hard-coded, vendor-defined processes and workflows are no longer feasible. Instead, the solution needs to be able to take a canonical payment object and orchestrate its flow through different services depending on its specific characteristics. |
| The typical workflows are likely to differ depending on any dimension discussed in the Scope (A), such as, instrument type (e.g., credit transfers will be processed differently from direct debits), channel, customer or transaction type (e.g., returns vs. outgoing payments). The flow for a large value international payment is likely to be a lot more complex, involving many more steps than the processing of a low-value domestic transaction. The networks (CSMs) will also have “standard basic flows” that will be different from one another (e.g., BACS and NACHA). |
| In addition to these “basic differences,” modern payment services hub solutions should allow further customisation of workflows, for example, to take into account different service level agreements that the bank might have with different customers or to differentiate between the “vanilla” products (e.g., expedite vs. standard transfer). These additional rules should be easy to introduce, and ideally should be done by the business users and not require IT involvement. |
| Finally, the solution needs to be capable of dealing with various exceptions along the way and determine what to do next even if the current step cannot be completed. Such intelligence further aids straight-through processing. |
| Business process management (BPM) tools are often used to define and manage custom workflows, and there are a number of off-the-shelf commercial BPM packages available in the market. If the bank has already purchased a BPM tool, it may also wish to use it to orchestrate the various payment services within the modern PSH. |
| Such approach is often referred to as “coarse-grain” orchestration. It works well to orchestrate a high-level payment flow (e.g., validation, enrichment, etc.). However, validation service would be very different depending on the context (i.e., what kind of validation is required for the customer, account, instruction, etc. will be determined by the nature of the transaction). Due to performance- and efficiency-related considerations, such “fine-grained” orchestration tends to be delivered via rule-based workflow management embedded within the payment services hub. |
2.3.3. Monitoring and Alert Capabilities |
| A modern payment services hub solution should have all transaction data available online and real time, subject to the required access rights. |
| The solution should come with a standard (but customisable) set of reports which can be generated automatically or on an ad hoc basis. However, the bank should be able to define the reports and monitoring dashboards based on its own or its customers’ needs. The bank should be able to set up alerts for specific payments, payments queues, liquidity events, or security violations. When setting up alerts, the bank’s business users should be able to define the content, recipients, and any specific criteria. Finally, real time SMS/email alerts for configured processing events should be available. |
| For advanced Business Activity Monitoring (BAM) functionality, a modern payment services hub solution should be able to integrate with third party tools available in the market (e.g., Tivoli, HP Open View, Systar). |
2.3.4. Security, Access Control, and Audit Trail |
| Of course, given the sensitive nature of payments processing, security and access controls are of paramount importance. In addition, given that, in the payment services hub, business users have a much higher degree of control and are able to define workflows and reports, it is critical to have an audit trail for all the user activities. |
| A modern solution should comply with the enterprise security standards and techniques. User access rights should be controlled by user profiles, and only administrators should authorise users to gain read/write access to functions, message queues, and message types. Some solutions deploy dual access controls. The functional access profiles define what functionality a user can access; the data access profiles define what additional filters on the database query need to be applied (e.g., some users can only see accounts from their department). |
| The solution should track all changes to any record in the system and create an audit trail of the transaction as it passes through each workflow step. The audit trail should show all manual and automatic actions performed on messages as well as all modifications made to maintenance setups (e.g., customer or account records.) The audit trail should display all relevant IDs, dates, and times for each modification and should include “before” and “after” images of the changed transaction. It should be viewable in real time and accessible online or via reports. Also, for obvious reasons, it should not be possible to change or delete the audit trail. |
2.3.5. Reliability and Scalability |
| The final requirement in Celent’s definition of a visionary PSH is that the solution should process all transactions “reliably at large volumes.” |
| Both aspects are important here: large volumes and reliability. Payment volumes continue to grow around the world. In addition, the payment services hub consolidates various payment transactions that would have been processed by multiple systems onto a single platform. The PSH needs to be able to process millions of transactions an hour. For example, Logica’s LAPS solution has been benchmarked to process batches of SEPA transfers at a rate of 50 million per hour and wholesale FedWire payments at 85 thousand per hour. |
| This last point also explains why reliability for a payment services hub is even more critical than it is for most payment systems. Given the concentration of payments, if a hub fails, the bank’s ability to process payments is severely disrupted. In fact, this approach of putting all eggs into one basket is one of the biggest risks and criticisms of payment services hubs. Some of the solutions, such as Polaris’ Intellect Payment Services Hub (IPSH), are deployed in a clustered environment that enables parallel processing of transactions. Also, IPSH is deployed in an Active-Active or Active-Passive mode and clustering tools are used to ensure quick recovery in case of a system failure. |
3. PAYMENT SERVICES HUBS IN PRACTICE |
| Celent’s definition of payment services hub is unlikely to be contentious. Most industry experts are likely to recognise it and agree with its key statements. |
| However, confusion remains, partly because Celent’s definition is an architectural vision. It can guide any bank embarking on a payments infrastructure modernisation project; however, in practice, it is unlikely that any bank will get to this visionary state any time soon. For some, the business case will simply not stack up. For others, the effort might be prohibitively large, given their starting point and ambitions. |
| During this research, Celent determined that there are four main types of payment services hubs being built by banks today (see Figure below), which contributes to the lack of agreement on terminology. |
 |
| Each bank decides which type of payment services hub to implement depending on its specific situation (e.g., critical pain points, future ambitions). The rest of this section describes the four types in more detail and discusses the most common conditions under which a bank might choose to implement that particular type. |
3.1. CHANNEL INTEGRATION HUB |
| In this type of implementation, the multiple channel systems connect to a single channel integration hub, which then feeds the payments into the appropriate payment processing platforms. Such approach replaces the traditional many-to-many connections between the channel systems and the payment processing platforms. |
| This approach is particularly useful when upgrading or introducing new channels and products—not having to integrate with multiple payment processing platforms increases the product’s speed to market. |
3.2. CSM INTEGRATION HUB |
| In this type of implementation, the connections to multiple Clearing and Settlement Mechanisms are integrated within a single CSM integration hub. Payment processing still happens within multiple platforms, but the hub again replaces the traditional manyto- many connections between the payment processing platforms and CSMs. In addition, the hub can aggregate the processing volumes for a particular network if appropriate. |
| This approach is particularly useful when the bank needs to maintain access to multiple networks and CSMs, which becomes especially important if the bank operates internationally. |
| The implementation of such a hub is often accompanied by the centralisation of payment operations, which manages payment repairs, authorisations, and interactions with the networks from a single location. Such an approach is sometimes referred to as a payments factory. |
| “Payments factory” is also the name often given to payment hub implementations within corporations (i.e., when a corporate client consolidates its payment operations and processing into a single location). Celent favours reserving the term “payments factory” for such implementation. |
| Finally, the first two types can be implemented without exposing payment functionality as services and without realising many of the benefits of a true payment services hub. In that case, the term “payment hub” is often used and is more appropriate. |
3.3. PAYMENT ORCHESTRATION LAYER |
| In this case, the payment processing platforms remain intact and continue to provide payment processing functionality, whether within the dedicated payments engines, core banking systems, or other systems in the bank (e.g., Treasury). |
| In the past, banks that wanted to go beyond the payments functionality provided by the core banking or in-house built systems would implement a payments engine: a dedicated payments solution to provide end-to-end payment processing, usually for a specific payment type (frequently high-value / high-care payments). As we will see from the fourth example of a payment services hub, the engine functionality is still an important component of a hub. The differences between a modern hub-type solution and a traditional engine have less to do with functionality and more with technology architecture: the traditional engines used to be monolithic software packages with limited flexibility and functionality hard-coded rather than delivered as services. |
| If a bank feels that its dedicated payment engines remain adequate (at least for the time being), or it would like to preserve an investment made into customising and adding components to the existing solutions, then the third payment services hub type—an orchestration layer—is a viable option. |
| An orchestration layer typically incorporates channel and CSM integration capable of handling multiple payment types and CSM formats. However, in addition, it orchestrates the payment workflows with rule-based processing, manages all the exceptions, and provides real-time business activity monitoring and delivery of information. |
| It tends to have dedicated capabilities to define and manage payment workflows through configurable business rules. The workflows can take factors such as network cut-off time and customer SLA into account. |
| It also has functionality designed to increase STP rates, such as message/file parsing, formatting, data validation and enrichment, and advanced exception management capabilities, including repairs. |
| Finally, it gives real time access to payment information through dashboards, reporting, and alerts, enabling increased visibility and better management of payments within the bank, as well as ability to create information-based value-added services to the bank’s customers. |
3.4. VERTICAL PAYMENT SERVICES HUB SOLUTION |
| Finally, there are situations when a bank feels that it is ready for a major upgrade and a gradual replacement of its legacy payments solutions. Sometimes an external requirement (e.g., the need to process SEPA payments in Europe) is a strong impetus for change. |
| In such cases, a vertical payment services hub solution is appropriate. It includes not only the channel and CSM integration and the payment orchestration layer, but also the payment processing functionality that used to reside within the payments engines or other systems. |
| It is unlikely that a bank will choose to migrate all types of payments to the new solution at once. Instead, a bank would typically start with the areas that are most in need of replacement or have the greatest opportunities for additional revenues. |
4. ADDITIONAL TERMINOLOGY CONSIDERATIONS |
| For some industry participants, the solution only qualifies as a payment services hub if it is a multi-entity implementation (i.e., if a bank uses the solution to insource payments from other banks). While the ability to process payments from other FIs (just like any other customer) is one of the requirements in Celent’s definition, we don’t think it is a “must-be-present” criterion; a solution without it could still be called a payment services hub. |
| Also, “payments engine” and “payment services hub” continue to add to the terminology confusion. Some vendors that historically had a payments engine product are in the process of rearchitecting it and are keen to position it as a payment services hub. Others may have developed a modern solution which has all the characteristics of a payment services hub as defined in Celent’s vision, yet chose to call it a payments engine. It is important to go beyond the nomenclature when trying to understand various vendor offerings in this space. |
5. CONCLUSION |
| In this paper, Celent has sought to provide clarity around the definition and terminology of payment services hubs. Key takeaways are: |
| • A true payment services hub is a solution that is capable of processing any payment on a single platform, irrespective of instrument type, value of payment, customer, channel, or transaction type; delivers core payment processing functionality for each of those scenarios; and is built on a modern technology architecture. |
| • For now, payment services hub is an architectural vision. No bank has implemented a complete payment services hub. |
| • Instead, banks focus their efforts on building one of four types of less ambitious payment services hubs: channel integration hub, clearing and settlement mechanism (CSM) integration hub, payment orchestration layer, or a vertical payment services hub. |
| • The first two types can be implemented without exposing payment functionality as services, in which case use of the term “payment hub” is appropriate. |
| • Celent favours reserving the term “payment factory” for payment hub implementations within corporations. |
| • The solution does not have to be a multi-entity (multi-bank) implementation to qualify as a payment services hub. |
| • Typically, “payments engine” refers to a dedicated solution to provide end-to-end payment processing. A traditional payments engine is, however, a monolithic software package with limited flexibility and functionality hard-coded rather than delivered as services. |
| • Having said that, a solution shouldn’t be dismissed just because it might be called “payments engine.” Some of them might be fully capable payment services hub solutions. |
ABBREVIATIONS |
| • ACH – Automated Clearing House |
| • ATM – Automated Teller Machine |
| • BAM – Business Activity Monitoring |
| • BIC – Bank Identifier Code |
| • BPM – Business Process Management |
| • CSM – Clearing and Settlement Mechanism |
| • ERP – Enterprise Resource Planning |
| • FI – Financial Institution |
| • FX – Foreign Exchange |
| • IBAN – International Bank Account Number |
| • ISO – International Standards Organisation |
| • J2EE – Java 2 Enterprise Edition |
| • OFAC – Office of Foreign Assets Control |
| • POS – Point of Sale |
| • PSH – Payment Services Hub |
| • RTGS – Real Time Gross Settlement System |
| • SEPA – Single European Payments Area |
| • SLA – Service Level Agreement |
| • SMS – Short Message Service |
| • SOA – Service Oriented Architecture |
| • STP – Straight Through Processing |
| • XML – eXtensible Markup Language |
References |
|
Copyright © 2024 Research and Reviews, All Rights Reserved